Goto fail. Go directly to fail. Do not pass go.
What the heck does that mean, you may ask? Well, on Friday, Apple issued an update to iOS, version 7.0.6. The update was issued with the very intriguing text, "This security update provides a fix for SSL connection verification." Now, to many consumers, this no doubt seemed like gibberish, so I imagine many people glossed over it and didn't take it seriously.
To the security community, on the other hand, these words had fail written all over them. Indeed, it didn't take the community long to dig deeper into what was going on.
Over the weekend, a Google engineer (Adam Langley) published some additional details. The problem lies in a small piece of Apple's open-source published code:
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
uint8_t *signature, UInt16 signatureLen)
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
Notice the two consecutive lines there that read "goto fail"? Well, there should only be one of them. In fact, the second one causes every execution of this code to jump to "fail:" below, thereby failing to properly validate an SSL connection. (There was other code as well, but this second "goto fail" is where the problem crept in.)
The result? An attacker could successfully perpetrate a man-in-the-middle attack on any piece of software that used Apples SSLVerifySignedServerKeyExchange method to test the validity of an SSL connection. Hint: the list is long.
Goto fail indeed.
But so Apple issued a patch, right? So what's the big deal? Well, according to Langley, the problem also affects OS X up to and including the current version 10.9.1. Uh-oh...
That is where the real fail lies, notwithstanding the extra "fail" in the source code.
I'm writing this on Monday morning, Feb. 24, and as of this moment, we still have a vulnerable OS X with no official patch from Apple. That's a lot of vulnerable Macs out there, folks.
Some folks are citing an unofficial patch, which may or may not work fine, but I'm disinclined to deploy or suggest to anyone (other than perhaps a software techie who wants to experiment) to deploy an unofficial patch.
I find myself simply scratching my head and wondering why Apple would release an iOS patch in the absence of an OS X patch, since both systems were affected by the same bug.
Why on earth wouldn't the iOS and OS X team coordinate a single release of both patches? Could it be there's an ongoing attack on iOS that I'm not aware of? Perhaps. Could it be that the iOS security team and the OS X security team are incapable of any meaningful collaboration on such a bug and patch? I have to say I'm more inclined to accept the latter explanation, sadly. I sincerely hope I'm wrong.
For that matter, I'm also more than slightly troubled that a bug like this, which appears to be nothing more than a simple human coding mistake, could go unnoticed during a static code analysis or security testing of the code. After all, we're talking about some hugely sensitive security code. SSL connection verifiers should undergo extensive code review as well as testing. Every logical aspect of that code should be tested using fuzzing and other security testing methodologies that are well known and accepted in the software security community.
Anyone who has read more than a couple of my columns shouldn't be surprised to hear that I'm a fairly heavy Apple user. I use a pretty full suite of Apple kit in my work, from my iPhone 5S to my iPad "3" and my Macbook Pro -- without a doubt the best laptop I've ever experienced.
Apple has not done us users any favors in how it has chosen to fix this bug. Patching iOS and leaving OS X vulnerable is at best highly unprofessional. Shame on Apple!
Goto fail indeed. Go directly to fail. Do not pass go. Do not collect $200.
With more than 20 years in the information security field, Kenneth van Wyk has worked at Carnegie Mellon University's CERT/CC, the U.S. Deptartment of Defense, Para-Protect and others. He has published two books on information security and is working on a third. He is the president and principal consultant at KRvW Associates LLC in Alexandria, Va.