A critical iOS vulnerability that Apple patched on Friday gives attackers an easy way to surreptitiously circumvent the most widely used technology for preventing eavesdropping on the Internet. That made the security bug about as dire as one can be. Now, there's strong evidence that the same flaw also exposes sensitive e-mail and Web communications on fully patched versions of OS X, with no indication that there is a patch currently available for the millions of people who use the Mac operating system.
At this early stage, the vulnerability has been confirmed in iOS versions 6.1.5, 7.0.4, and 7.0.5, and OS X 10.9.0 and 10.9.1, meaning it has silently exposed the sensitive communications of millions of people for weeks or months. Security researchers haven't ruled out the possibility that earlier versions are also affected. Readers should immediately update their iPhones and iPads to versions 7.0.6 or 6.1.6, preferably using a non-public network.
For the time being, people using Macs should avoid using public networks, a step that can thwart many criminal eavesdroppers but will do little to prevent surveillance by the National Security Agency and other state-sponsored spies. Because the Google Chrome and Mozilla Firefox browsers appear to be unaffected by the flaw, people should also consider using those browsers when possible, although they shouldn't be considered a panacea.
The flaw, according to researchers, causes most iOS and Mac applications to skip a crucial verification check that's supposed to happen when many transport layer security (TLS) and secure sockets layer (SSL) connections are being negotiated. Specifically, affected apps fail to check that the ephemeral public key presented by servers offering Diffie Hellman-supported encryption is actually signed by the site's private key. Attackers with the ability to monitor the connection between the end-user and the server can exploit this failure to completely decrypt and manipulate the traffic by presenting the app with a counterfeit key.
An attacker "can basically set up a connection and pretend to be Google.com," Matt Green, a Johns Hopkins University professor specializing in encryption, told Ars. The attacker "can basically say: 'Hey I'm Google, here's my signature. And since nobody is actually going to check the signature, [the attacker] just puts nonsense in there."
Independent security researcher Ashkan Soltani has confirmed that Safari and Mail.app, the default browser and e-mail client in OS X, suffer from the verification error in version 10.9.1. He and other researchers say virtually all applications that rely on the SecureTransport TLS layer are susceptible to the attack, regardless of whether they use a technique known as certificate pinning designed to block counterfeit encryption certificates. The bug, according to this analysis by encryption expert and security engineer Adam Langley, is the result of a single line of misplaced code that instructs apps to skip the verification check of the ephemeral key.
"This sort of subtle bug deep in the code is a nightmare," Langley, who is also a Google employee, wrote. "I believe that it's just a mistake and I feel very bad for whomever might have slipped in an editor and created it."
People who know how to read source code can easily identify the bug in the following lines:
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;
}
In the two "goto fail" lines in a row, the second one isn't conditional. As a result, it causes the app to terminate the verification.
"This is somewhere between an understandable mistake and ouch," Green said.
Testing 1, 2, 3
Langley has set up this test page, which is signed with a key that doesn't match the underlying TLS certificate. Apps that are able to access the text without generating an error are presumed vulnerable. While Chrome is one of the few applications that isn't susceptible to the attack, Langley said it wasn't clear if the update mechanism for the Google browser is vulnerable. If so, it would mean that attackers may still be able to compromise Chrome users, at least in some cases. It's unclear if Firefox is vulnerable to similar techniques, but until Mozilla representatives weigh in, readers should leave open that possibility as well.
Apple representatives, meanwhile, have yet to issue any public statements beyond the vague but spooky two sentences contained in Friday's advisory. They read:
Impact: An attacker with a privileged network position may capture or modify data in sessions protected by SSL/TLS
Description: Secure Transport failed to validate the authenticity of the connection. This issue was addressed by restoring missing validation steps.
Apple rarely comments on matters involving security, particularly those involving vulnerabilities that remain unpatched. That makes it hard for Ars to provide complete and fully confirmed details about the extent of the encryption flaws being publicly discussed in response to the latest iOS updates. Given the serious warnings being issued over social media, Ars is weighing in now, out of an abundance of caution.
It's possible there are mitigations available in OS X that make Macs less susceptible to attacks, but until there is more conclusive information available, Mac users should anticipate the very real possibility that TLS encryption in Safari, Mail, and many other apps is susceptible to attacks that are trivial to carry out. And of course anyone with an iPhone or iPad should make sure they're running the latest version.
reader comments
204