Apple SSL Bug In iOS Also Affects OS X

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."

Comments

Hmm...

[93 Escort Wagon]

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

Coincidence? I think not!

Informative discussion thread

[MisterSquid]

Over at MetaFilter, there's a pretty informative thread calling out these parts among others.

• 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 to see if your device/browser is affected.

Re:Lets see how far back...

[ugen]

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.

NSA

[Qwerpafw]

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...

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:NSA

[93 Escort Wagon]

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.

Re:NSA

[Your.Master]

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 is a C Standard Bug

[Harry8]

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... 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!!

Re:Apple

[Anonymous Coward]

I bet your mom gives out root access to the world.