is a shocking and embarrassing one. That it appears to have been in both iOS and OS X for some time and the way Apple is addressing it show both that Apple knows how serious it is and that Mac users play second fiddle in Apple's orchestra.
Make no mistake about it, this is a very serious bug. The bug makes it fairly straightforward to intercept and decrypt SSL/TLS communications, probably the most important security protocol there is today. Any time you see Apple (or really any major vendor) release an update that fixes a single bug, you can be sure it's a high-priority bug. And there's no reason to believe that it's higher-priority for iOS users than for Mac users. So why did they not fix OS X at the same time? Because OS X isn't top priority anymore.
[UPDATE: Reuters is reporting that Apple tells them a fix for OS X is being tested and will be released "very soon".]
[UPDATE 2: Exactly why Apple waited to release the OS X patch became clear four days later when.]
The analysis of the bug by Google's Adam Langley on his personal blog shows clearly what happened. He was able to find it rather easily using the scant information provided by Apple because the code in question has been open-sourced by Apple. Contrary to some claims, Apple did not just use OpenSSL, at least not for this code. There is only one copyright statement and it is Apple's.
The error is a simple one that's easy to see when you look right at it, but perhaps hard to see when you're looking at the whole 1,970 line file. The error is on line 632. It's an extra "goto fail;" statement that causes SSL signature verification to succeed always (in certain very common configurations). For more detail on all this, read Langley's post. It has the look of a thoughtless editing bug — a slip of the fingers — rather than an error in logic. The fix is simply to remove line 632 and recompile.
Note that Stefan Esser has released an unofficial patch for the bug on OS X 10.9 (Mavericks). He warns that the patch is not for novices.
Incidentally, lest anyone think Langley views Apple as a competitor in this regard, think different. Langley is well-known for working to improve the strength of Internet security generally. He makes clear that he feels bad for the Apple developers who made the mistake, that it could happen to anyone, and that in any software project so large and complex, mistakes are inevitable. Even so, such errors should be found in code review.
We don't know how the bug was found. They don't credit anyone in the security bulletin. It's possible that they found it in an internal code review. It's possible a third party found it and brought it to Apple's attention (although normally you would expect that party to be credited). It's possible they became aware of exploits of the bug and haven't disclosed the fact. This last possibility might also explain why only iOS was patched so far, if perhaps the exploits are somehow only targeting iOS. But I'm speculating, which is all I can do when Apple leaves an information vacuum.
Another sign that Apple views this as an über-high priority bug: They also issued a patch for iOS 6. Apple doesn't want any users on iOS 6 and likes to brag about how quickly iOS users migrate to the next major version. Over two months ago Apple claimed that . There hasn't been a security update for iOS 6 in almost a year. I'm sure Apple doesn't want to do anything to make it easier for iOS users to stay on iOS 6, but they patched it anyhow. That's how serious it is.
[UPDATE: The update for iOS 6 is available only for the iPhone 3GS and 4th generation iPods. The iPhone 4 and 4S, which are capable of running iOS 7, are only offered iOS 7.0.6 to address the SSL/TLS bug, even if they are running iOS 6.]
We don't know how old the bug is. At first I was inclined to believe that it had been around a while, but that's not clear anymore. Fortunately for Mac users who have not upgraded to OS X 10.9 (Mavericks), it appears from the early tests that OS X has only had the bug since version 10.9. It was in both iOS 6 and 7.
This episode says something interesting about open souce as well. This code was published for all to see and appears to have been there for a year at bare minimum, and yet it's clear that nobody, inside or outside Apple so much as ran it through a serious static source code analyzer.
Should it have been found at compile time? Langley notes that if he compiles the code using Apple's Clang 3.3 from Xcode with the -Wall option to enable all warnings, he gets no warning about the problem. Peter Nelson points out on Twitter that there is a separate -Wunreachable-code option which does find it, but which is not included as part of -Wall. Mark Janssen says that -Weverything does include it and finds the bug. (Therefore, "everything>all == 1" to Xcode.) So it could have been found, but it also seems like the tools are confusing even to experts.
Speaking of compilers and warnings, Stefan Esser tells me that even though the compiler doesn't warn of the unreachable code, it is smart enough to optimize it away. His unofficial patch has to recreate the missing code rather than just NOP over an extraneous goto.
The whole episode, which is still not over, makes me wonder about code review at Apple. Bugs like this are bound to happen in any organization, but it's shocking that they could sit undetected for so long.