Yesterday Apple released updates for iOS 6, iOS 7, and Apple TV to squash a security bug that affected SSL/TLS connections. Often times, security patches can fix obscure bugs that could only occur under the strangest of circumstances, and they get rolled in to larger updates that address many other issues. However, this fix warranted its own updates, both for iOS 7 and for iOS 6. So what kind of bug calls for such a response? Fortunately for those of us curious enough to wonder, Adam Langley has the answer.
First of all, any time you have a bug that affects SSL/TLS you should pay close attention. As a quick refresher, SSL/TLS refers to encryption protocols that are widely and commonly used to encrypt the transmission of sensitive data. Any bug affecting SSL/TLS has the ability to undermine many, if not all, of the secure transmissions made from your devices.
The bug Apple fixed was the result of a stray line of code. It exists in a block of code that is responsible for validating the identity of a server. When your browser makes a secure connection to a website, the site presents your browser with certificate chain. Your browser will check the site's certificate to make sure that it's for the site you're connecting to: apple.com can't present you with a certificate that says it's for google.com. Your browser will also verify that the certificate was issued by a trusted certificate authority: I can generate a certificate for google.com, but I am not a trusted certificate authority so that certificate should not be accepted by anybody. Finally, your browser verifies the certificate chain's signature with the website's public key. Even if I create a fake certificate chain, the key I use to sign it won't match the site's public key. This is where Apple's code was failing. Below is the relevant snippet from Apple's published open source code:
static OSStatusSSLVerifySignedServerKeyExchange(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;}The if statements in the code above are part of iOS's signature verification for particular cipher suites that can be used in SSL/TLS. In the second if statement you see an if statement followed by two "goto fail" lines. The second one is the cause of the bug. The result of this code is the portion where the server's signature is validated never gets executed. The code attempts to validate the certificate, but after validating the certificate and before it validates the certificate's signature, the code will always hit that second "goto fail" statement, which effectively skips over that last bit; the part where the signature is validated. This bug affects any software that uses Apple's SecureTransport API for making SSL or TLS connections, including Safari and many third-party apps.
The result of this code is that an attacker on the same network as you could perform a man-in-the-middle attack where they fake a certificate keychain to a secure site, like your bank. You can't trust any secured connections in affected version of iOS and OS X. Everybody should update their iOS devices and Apple TVs if they haven't already.
Unfortunately, OS X remains vulnerable to this attack. Given the severity of this bug, it's surprising that Apple hasn't rolled out an OS X update yet, but we'll hopefully see one soon.
Update 1: People wishing to check to see if they're vulnerable can go visit the site gotofail.com. Safari in OS X will show as vulnerable until Apple deploys a fix, while Firefox and Chrome are not currently susceptible since they use different libraries for encryption.
Update 2: Apple spokesperson Trudy Muller has confirmed to Reuters that the OS X update is coming soon.
