Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
OS X Bug IOS Security Apple

Apple SSL Bug In iOS Also Affects OS X 140

Posted by timothy from the sympathetic-reaction dept.
Trailrunner7 writes "The certificate-validation vulnerability that Apple patched in iOS yesterday also affects Mac OS X up to 10.9.1, the current version. Several security researchers analyzed the patch and looked at the code in question in OS X and found that the same error exists there as in iOS. Researcher Adam Langley did an analysis of the vulnerable code in OS X and said that the issue lies in the way that the code handles a pair of failures in a row. The bug affects the signature verification process in such a way that a server could send a valid certificate chain to the client and not have to sign the handshake at all, Langley found. Some users are reporting that Apple is rolling out a patch for his vulnerability in OS X, but it has not shown up for all users as yet. Langley has published a test site that will show OS X users whether their machines are vulnerable."
This discussion has been archived. No new comments can be posted.

Apple SSL Bug In iOS Also Affects OS X More

Apple SSL Bug In iOS Also Affects OS X

Comments Filter:

  • Hmm... (Score:4, Funny)

    by 93 Escort Wagon ( 326346 ) on Saturday February 22, 2014 @05:00PM (#46312893)

    The researcher who found the bug is Adam Langley. CIA headquarters is in Langley, Virginia.

    Coincidence? I think not!

    • The researcher who found the bug is Adam Langley. CIA headquarters is in Langley, Virginia.

      Coincidence? I think not!

      Adam Langley is an anagram of "A lang madly e". Clearly this is the product of some leet Canadian insider who has gone rouge with this disclosure. Time to put on a new layer of tinfoil.

      • The researcher who found the bug is Adam Langley. CIA headquarters is in Langley, Virginia.

        Coincidence? I think not!

        Adam Langley is an anagram of "A lang madly e". Clearly this is the product of some leet Canadian insider who has gone rouge with this disclosure. Time to put on a new layer of tinfoil.

        Mascara, even!

        • Re: (Score:2)

          by sjames ( 1099 )

          Must be a lumberjack.

        • Re: (Score:2)

          by Meski ( 774546 )

          The researcher who found the bug is Adam Langley. CIA headquarters is in Langley, Virginia.

          Coincidence? I think not!

          Adam Langley is an anagram of "A lang madly e". Clearly this is the product of some leet Canadian insider who has gone rouge with this disclosure. Time to put on a new layer of tinfoil.

          Mascara, even!

          I dunno, it's making me see red...

    • >> The researcher who found the bug is Adam Langley.
      >> Bug removes SSL ...

      it's a feature, not a bug.
      https://pbs.twimg.com/media/Bh... [twimg.com]

  • Lets see how far back... (Score:2, Insightful)

    by Anonymous Coward

    Let see how far back Apple will patch this thing, if they leave Snow Leopard (10.6) out for the wolves or not.

    In the past under Jobs, only the last two OS X versions got security updates. He was a real prick about trying to force people to upgrade to their latest bloated your machine so you have to buy a new one prematurely crap.

    • Re:Lets see how far back... (Score:5, Insightful)

      by ugen ( 93902 ) on Saturday February 22, 2014 @05:08PM (#46312955)

      Snow Leopard (10.6) is not vulnerable to this bug, since Apple did not switch from OpenSSL to their own SSL/TLS library back then yet. Just verified on my 10.6 box (to verify visit https://www.imperialviolet.org:1266/ )

      On the other hand, iOS 6.1.5 is - and now I have a choice of using insecure iPhone or upgrading to 7.x. For now I've switched from Safari to a 3rd party browser that does not have this bug - but email is still vulnerable and so can be other components. That said, I have little trust in SSL even when it works as designed, so I won't lose much sleep over this.

      • Snow Leopard (10.6) is not vulnerable to this bug, since Apple did not switch from OpenSSL to their own SSL/TLS library back then yet. Just verified on my 10.6 box (to verify visit https://www.imperialviolet.org... [imperialviolet.org] )

        On the other hand, iOS 6.1.5 is - and now I have a choice of using insecure iPhone or upgrading to 7.x.

        Or, perhaps upgrading to iOS 6.1.6 [apple.com] which corrects that bug.

        • Re: (Score:1)

          by Anonymous Coward

          If you are able to upgrade to iOS 7, you are not able to upgrade to 6.1.6.

          • If you are able to upgrade to iOS 7, you are not able to upgrade to 6.1.6.

            Ugh. I didn't realize that. That's just...short-sighted.

        • Re: (Score:3)

          by ugen ( 93902 )

          iOS 6.1.6 is not available for iPhone 5. It is only available for devices for which there is no iOS 7, unfortunately. First thing I checked.

      • Re: (Score:3, Interesting)

        by dgatwood ( 11270 )

        Snow Leopard (10.6) is not vulnerable to this bug, since Apple did not switch from OpenSSL to their own SSL/TLS library back then yet.

        No, that's not correct at all. First, it doesn't affect 10.8.5, either, which blows that theory. Second, Secure Transport was introduced way back in 10.2, and has been used for Foundation and Core Foundation SSL negotiation since at least 10.4, according to various security vulnerability reports (and probably earlier). In other words, this has absolutely nothing to do with

        • Re: (Score:3)

          by ugen ( 93902 )

          It is correct and, if you have 10.6 handy - you can verify that under that system Safari is using OpenSSL. To do so, simply move /usr/lib/libssl.*.dylib elsewhere and try to run Safari. It will fail due to missing libraries.
          On 10.9 Safari will happily run with OpenSSL libraries removed.

          You are welcome to dig through otool -L output to find how it's linked up, but the fact remains - Safari was switched over from OpenSSL to homegrown crypto sometime after 10.6.

          • Re: (Score:2)

            by dgatwood ( 11270 )

            Even if you're right, the fact remains that security researchers have shown that the bug in question didn't exist in Secure Transport as of the 10.8.5 sources. Because Secure Transport is open source, you can verify that yourself if you don't believe me.

      • since Apple did not switch from OpenSSL to their own SSL/TLS library back then yet.

        Why did they switch? I haven't been able to find out from the articles I read.

      • If you don't want 7.x you can use 6.1.6 which got released to fix this

        • Re: (Score:3)

          by PNutts ( 199112 )

          Not on all devices. AC posted this so it got lost in the filters: If you are able to upgrade to iOS 7, you are not able to upgrade to 6.1.6.

      • Re: (Score:2)

        by mattr ( 78516 )

        Slashdotted.

      • I just checked with https://www.imperialviolet.org... [imperialviolet.org] And I got the message "Safari can't open that page because Safari can't established a secure connection to the server". I am running Mac OS 10.8.4 so does that mean I am safe?

    • 10.8.5 isn't even effected, why would any previous version be? This is strictly an iOS 6.x, iOS 7.x and Mac OS X 10.9.x bug.

  • Informative discussion thread (Score:5, Informative)

    by MisterSquid ( 231834 ) on Saturday February 22, 2014 @05:05PM (#46312937)
    Over at MetaFilter, there's a pretty informative thread calling out these parts among others [metafilter.com].
    • iOS 6 users with iOS 7-capable devices will be given the latest iOS 7.
    • iOS 6 users without iOS 7-capable devices will be given the latest iOS 6
    • Mac OS X users pre-Mavericks (10.9) are OK.
    • Mac OS X Mavericks users should avoid using Safari.
    • You can visit this link [gotofail.com] to see if your device/browser is affected.

    • Re: (Score:1)

      by ugen ( 93902 )

      :( But I *really* don't want iOS 7. I think this is all planned by Apple to move remaining holdouts to the current iOS. Fuck.

      • iOS 7 is the worst mobile OS I have ever seen.
        If you are an iPhone, iPad user I recommend not to upgrade to it.
        The UI is the absolute ugliest thing I can imagine, many superb iOS applications like the address book or the Calendar or the Notes application look like utter shit.
        The standard usability with swipes of a finger or multiple, fingers is completely messed up. The pad or the phone does most of the time not what you want, and if you want to do something special, like killing a process: it simply does

        • Re: (Score:1)

          by grub ( 11606 )
          I guess those are YMMV problems. Though I agree about the screen brightness one.

  • NSA (Score:5, Interesting)

    by Qwerpafw ( 315600 ) on Saturday February 22, 2014 @05:26PM (#46313023) Homepage

    Some bloggers and commentators online (no mainstream media news sites... yet) have suggested that this bug was introduced by the NSA based on the fact that Snowden's leaked slides showed evidence that the NSA had developed and was working on further ways of targeting and compromising secured iOS traffic.

    We know the NSA compromised RSA through Dual EC_DRBG. It's not hard to imagine they wanted to compromise SSL/TLS on Apple platforms.

    The bug was found via internal code review according to the credits for discovery, which means nobody else has disclosed they knew about this in the wild (so this is an exposed zero day crypto exploit on both OS X and iOS platforms).

    This link is informative - the kicker is he properly indented but obviously duplicated and incorrect "goto fail;"

    https://www.imperialviolet.org... [imperialviolet.org]

    static OSStatus
    SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
                                                                      uint8_t *signature, UInt16 signatureLen)
    {
            OSStatus err; ...

            if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
                    goto fail;
            if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
                    goto fail;
                    goto fail;
            if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
                    goto fail; ...

    fail:
            SSLFreeBuffer(&signedHashes);
            SSLFreeBuffer(&hashCtx);
            return err;
    }

    Maybe this came out due to bad coding practices, but the kind of bug where the code visually looks ok on the surface, compiles and passes without compiler warnings, and works fine aside from allow the comprise is very suspect.

    And at the minimum the NSA has been exploiting this rather than alerting people. Our government needs to stop weakening computer security and go back to working for the people, not against them.

    • Re: (Score:1)

      by Anonymous Coward

      Uh, wouldn't such code generate " never executed" warnings for everything after the dupe goto??

    • Re:NSA (Score:5, Insightful)

      by 93 Escort Wagon ( 326346 ) on Saturday February 22, 2014 @06:40PM (#46313351)

      This is a fundamental problem all the traitorous NSA behavior has created - every time something like this comes up, we're going to wonder if THEY are behind it. Problem is, that way lies madness... we can never really know.

      1) It could very well be an innocent coding error. Heck, I could see myself doing this one with the slip of the fingers in BBEdit. I probably HAVE done it at some point in time.

      2) It could be an intentional bug slipped in by someone on NSA's payroll.

      3) Or, it could be even more nefarious. Perhaps NSA has known about this, but thought the use case was too restricting. So they kept quiet until they were able to slip a more broadly exploitable hole in the development code (or, alternatively, something the compiler can slip into your output). Then, to force everyone to update, they reveal this older bug. We all update, and BAM! They've got us.

      We can't really know, anymore.

      • This is a fundamental problem all the traitorous NSA behavior has created - every time something like this comes up, we're going to wonder if THEY are behind it. Problem is, that way lies madness... we can never really know.

        1) It could very well be an innocent coding error. Heck, I could see myself doing this one with the slip of the fingers in BBEdit. I probably HAVE done it at some point in time.

        2) It could be an intentional bug slipped in by someone on NSA's payroll.

        3) Or, it could be even more nefarious. Perhaps NSA has known about this, but thought the use case was too restricting. So they kept quiet until they were able to slip a more broadly exploitable hole in the development code (or, alternatively, something the compiler can slip into your output). Then, to force everyone to update, they reveal this older bug. We all update, and BAM! They've got us.

        We can't really know, anymore.

        As Henry Kissinger is reputed to have said, "Even paranoiacs have enemies...."

        • Re: (Score:2)

          by AHuxley ( 892839 )
          What do we know over the past 40-50 years of telco/computer gathering?
          "DEA and NSA Team Up to Share Intelligence, Leading to Secret Use of Surveillance in Ordinary Investigations"
          https://www.eff.org/deeplinks/... [eff.org]
          Intentional bug slipped in might get noticed outside the more bespoke high end machine encoding production efforts of the 1960-70's.
          Software teams are big, staff from varied countries, backgrounds, skill sets, review, in-house (unknown) next gen automated testing software - a person making rep

      • 2) It could be an intentional bug slipped in by someone on NSA's payroll..

        Who says that 'someone' is on their payroll?

    • Re:NSA (Score:4, Interesting)

      by Your.Master ( 1088569 ) on Saturday February 22, 2014 @08:02PM (#46313633)

      This bug looks like the sort of bugs that can come from merging between different code branches in very large codebases. A duplicated line, or a missing line, is a common merge-conflict resolution, *especially* where essentially the same code was added in both branches and then merged together. As an example, if this was a refactor of an existing function that was made similarly in two branches, but a little extra trailing whitespace was clipped in only one branch, then you could get a duplicate line out of an automerge operation.

    • This sort of thing can be hard to see; this specific case is easy to spot due to the uniformity of the code around it. I've seen much harder to spot instances of things like this.

    • Re: (Score:2)

      by bondsbw ( 888959 )

      This is exactly why I NEVER EVER use multiline if statements without braces.

      • Nobody does intentionally. Because there's no such thing.

        It's single statement if blocks without braces that people should be avoiding as a matter of style.

        • Re: (Score:2)

          by bondsbw ( 888959 )

          Single line if statement:

          if (condition) statement;

          Multi-line if statement without braces:

          if (condition)
                  statement;

          Multi-line if statement with braces:

          if (condition)
          {
                  statement;
          }

          There is no good excuse for choosing multi-line without braces over the one with braces.

    • Re: (Score:2)

      by TFoo ( 678732 )
      Looks like a SCM merge error to me. That kind of stuff happens, unfortunately...

    • Re: (Score:1)

      by Anonymous Coward

      IMHO This should have been caught in the developer's IDE as a dead code warning.

      p.s. This should have also been caught by automated code coverage tests.

    • If it was an NSA bug why does it only affect the newest version of the OS, the version that still comprises a minority of OS X users out there. If the NSA had the power to insert a bug like that into Apple's codebase don't you think they would have made it work on more computers? 10.8 has had security updates come out after the release of Mavericks, so if the NSA was so powerful as to be able to get buggy code into Mavericks, why didn't they backport it to older versions of the OS?

  • This is a C Standard Bug (Score:4, Informative)

    by Harry8 ( 664596 ) on Saturday February 22, 2014 @05:28PM (#46313031)
    C and C++ still haven't fixed this egregarious bug in the standard. There is no reason for single line, un-braced blocks. People use them to show off how "cool" they are that they don't need to brace because it's only one line. It makes for difficult to spot bugs like this. We need to actually yell at the people on the standards committees to FIX THE BUGS in the standard. There are other really obvious ones and they all should be fixed before adding more new features. YES I'M LOOKING AT YOU C++14! There are plenty of ways you can make a new standard still work alongside code from an old one (compile old, broke, brittle, stupid code with a compiler flag indicating the old standard and new, beter files (yes "translation units c++") with the new one. Introduce a #THIS_FILE_IS_STUPID pragma to disable sanity on old code compiled with the new standard and plenty of others. Pick one, bless, it, implement it and FIX THIS CRAP http://opensource.apple.com/so... [apple.com] The 35th and 36th incidences of the words "goto fail;" in that file are the problem, not easy to spot until you look really closely and it's a bug that a sane standard would make impossible. FIX IT!!

    • I never saw a bug related to braces, this bug neither is.
      If at all the bug is (difficult to spot) because of a wrong indentation.
      Bottom line the bug is absolutely obvious. You read the code from top to bottom and you see the bug, or you don't has nothing to do with braces or indentation.
      It is the old C versus Python argument. The argument makes no sense. Either you can read the code and comprehend it or you cant.
      No compiler, bracing or anything else can prevent it.

      • You may claim the bug is obvious and yet it slipped through to production. So rather than bring up the blame-log on the indvidual developer - programmers make mistakes and enforcing coding standards such as indentation or braces help in identifying errors where errant coders fail.

        If indeed Apple does have a coding standard, then this one slipped through. Using an IDE to pretty-print the code according to the coding standard, prior to checkin, would have revealed the inconsistency of indentation in the dupli

        • I would say the main problem with this style of coding is the use of gotos.

          Well, most programmers laugh at me and call me unproductive when I spend roughly an hour every morning to visually check every change comming from the version control system. Meanwhile however most organizations use tools like fisheye and do a planned review on the changes.

          I don't know if demanding more braces help. I think in this particular code every condition in the ifs should be refactored into a function returning a boolean. Th

      • Either you can read the code and comprehend it or you cant.

        If that were true, no competent coder would ever have bugs in his code.

        It's like this sentence... Count the number of Fs.

        FINISHED FILES ARE THE RE-
        SULT OF YEARS OF SCIENTIF-
        IC STUDY COMBINED WITH
        THE EXPERIENCE OF YEARS.

        Most people, despite their fluency of the English language will miscount the number of Fs.

        Enforced braces, compilers that are indentation aware, and better detection of unreachable code would would all reduce the number of times that errors of the type in the SSL bug occur. That's an indisput

        • Ah, your point about the unreachable code, that makes sense.
          The rest is a matter of taste ... I blame it on the stupidity to chain if's and use gotos instead of writing one if with one else branch.
          Well, regarding your F count: the last line of your 'poem' contains none ;) I wonder why you think it is so difficlut to count them?

          • The last line contains one F. See, it's not so easy, is it?

            The vast majority of people will count 3 Fs in the text at the first attempt. Yet there are 6 Fs.

            And nobody bother claiming they got 6 Fs first time. Your bragging, true or false, won't change the point that understanding a language doesn't mean one can parse it perfectly every time.

            • THE EXPERIENCE OF YEARS
              There is no F.

              Well, I don't know if it is a language parsing problem.
              I started programming with Basic. To gotos right behind each other are always wrong. So for me it was simple.

              I don't brag, I simply state that having braces likely had not prevented the error. As your example with the F ... some people are bad with { and }

              • THE EXPERIENCE OF YEARS
                There is no F.

                So you got it wrong again. Here's a clue. What's the second letter of "OF"?

                I rest my case.

                • You are rigt, there is an F :)
                  Pretty interesting, indeed.
                  I only found it a few hours ago, or rather I did not, I only found it by googeling "count the Fs" problem.
                  The solution had it highlighted in a different colour, otherwise I had not seen it.
                  I moved my finger from letter to letter and still I did not see the F in the of, surprisingly, I saw the F in the other of, pretty strange.
                  (How ever I wonder why that should be IQ related, two web sites covering that topic said so)

    • Lint tools can catch this sort of unconditional goto which one would hope is never used intentionally by goto afficionados.

      • Compiler warnings or source code analysis tools are often ignored though, sadly, as an afterthought or distraction.

        • Not in reputable software teams. Generally the flags are set to report warnings as errors. And nothing with a warning would make it into a mainline build.

          There are occasions when a warning is unavoidable. But then that requires positive action to use use pragma to turn the warning off and back on again around the offending line. And that should be commented as to why. It can't be ignored.

    • I am a member of the C and C++ standards committees. I'm sorry to tell you your proposal is inane, and were it to come up I wilk veto it.

  • So how does "Researcher Adam Langley" get access to the code in order to do "an analysis of the vulnerable code in OS X"?

    Do these experts have access to the source via some agreement with the vendor?

  • At mine, the test site at https://www.imperialviolet.org:1266/ [imperialviolet.org] does not even load. Firefox says:

    Secure Connection Failed An error occurred during a connection to www.imperialviolet.org:1266. A PKCS #11 module returned CKR_DEVICE_ERROR, indicating that a problem has occurred with the token or slot. (Error code: sec_error_pkcs11_device_error)

  • "You're bracketing it wrong."

  • Why on *earth* does this code have G*T*'s in it! !!!!

Slashdot Top Deals

Never test for an error condition you don't know how to handle. -- Steinbach

Close