Apple's SSL iPhone vulnerability: How did it happen, and what next?

Apple has issued an urgent fix for a vulnerability in its SSL (Secure Sockets Layer) code, used to create secure connections to websites over Wi-Fi or other connections, for its iPhone, iPad and iPod Touch devices.

The fix, which is available now for both iOS 6 and iOS 7, appears to have been introduced in a code change made ahead of the launch of iOS 6.0.

It also affects Mac computers running Mac OSX – and there’s no fix announced yet, although Apple says one is “coming soon”.

The bug, and its discovery, raise a number of questions. Here’s what we do know, what we don’t know, and what we hope to know. (Apple declined to comment in relation to a number of questions we put about the vulnerability.)

Advertisement

How can I check whether I’m vulnerable?

Go to gotofail.com and see what message you get. If all is good you’ll get a green message. On an iOS device, you’ll get a warning to update. If you’re on a Mac, you’ll either get a yellow message (in a safe browser pointing out that other apps could be vulnerable) or a red message (telling you to patch your browser).

What should I do?

If you use an iPhone, iPad or iPod Touch, update its operating software. Go to Settings -> General -> Software Update. For devices using iOS 7, update to iOS 7.0.6; for devices on iOS 6 which can’t be updated to iOS 7 (the iPhone 3GS or iPod Touch 4G), update to 6.1.6.

Note that Apple isn’t offering an update to iOS 6 for devices which can be updated to iOS 7 (iPhone 4, iPad 2, etc). For those, your only options are to update, or live dangerously.

If you’re using a Mac on an older OS version, ie 10.8 (”Mountain Lion”) or earlier, you’re safe.

If you’re using a Mac on the newest OS, 10.9 (aka “Mavericks”), don’t use Safari to connect to secure websites until there’s an update. Use Mozilla’s Firefox or Google’s Chrome: they use their own code for connecting to secure websites. No bug has been found in that.

What did the bug do?

In theory (and perhaps, depending on who knew about it, in practice) it could allow your connections to secure sites to be spied on and/or your login details captured. Updating the software prevents that. The bug affected the SSL/TLS encrypted connection to remote sites.

What’s the importance of SSL/TLS?

When your device (handheld or PC) connects to a website using the SSL/TLS (Secure Sockets Layer/Transport Layer Security) method, the site presents a cryptographic “certificate” chain identifying itself and the authority which issued the certificate. Your device already has a list of issuing authorities which are trusted, and it will check the name of the site and the certificate it presents with that authority.

In theory, a certificate that has the wrong name for the site, or which hasn’t been issued by the authority, or which is out of date, won’t be trusted. At this point you’ll get a warning in your browser telling you that there’s something wrong and that you shouldn’t proceed or your data could be at risk.

A faked certificate could mean that the site you’re connecting to is actually being run by someone who wants to collect your user login details – as has happened in Iran. In 2011 the government there is reckoned to have used a certificate issued from a subverted certificated authority to set up a site which (through DNS diversion) could pretend to be Google’s gmail.com – and captured the data from dissidents who thought they were logging into the site.

So it’s important that your device can authenticate SSL certificates correctly. Sometimes you will come across sites where you get a certificate warning but which say you should trust it (for example because it’s a subsidiary with a different name from the one which owns the certificate). Be wary. Don’t approve certificates without being cautious.

What was the bug?

Due to a singe repeated line of code in an Apple library, almost any attempt to verify a certificate on a site would succeed – whether or not the certificate’s signature was valid. It would only throw an error if the certificate itself was invalid (due to being out of date, for example).

The bug is in the code below: it’s the second “goto fail;”, and would be carried out in every circumstance.

When did the bug appear?

In iOS 6.0, which went public in September 2012. It’s not yet clear precisely when the error appeared in Mac OSX, but it’s likely to be at the same time, since the mobile and desktop OSs use common code trees. The bug wasn’t there in the final version of iOS 5, 5.1.1, released in May 2012. The same code has apparently been carried forward through into iOS 7 and Mac OSX 10.9; it’s even in the latest versions of iOS 7.1, which is still in beta.

(The red lines are removed in the updated code; the green lines are added.)

It’s not an obvious difference unless you’re looking for it; in that case, it stands out like a sore thumb to any programmer.

How did the bug get there?

Here we have two divergent theories: accident or conspiracy. Either it’s a stupid mistake inside Apple, or it’s a nefarious plan by the NSA (or others?) to ensnare targets’ communications by planting a back door in a key piece of code.

Arguing against the conspiracy plan is the fact that Apple publishes this code on its open source page. On the basis that “many eyes make bugs shallow”, and that the whole internet has been able to look at this epic “goto fail” for ages. If the NSA puts its secret backdoors out in the open like this, you’d expect them to be found a lot faster.

Arguing for nefarious conspiracy is – well, not very much. Apple should have found it, but didn’t; either of its compilers (GCC and Clang) should have thrown an error, but testing by others has shown that it doesn’t unless you have a particular warning flag (for “unreachable code”) set. A compiler which pointed to “unreachable code” (that is, a segment of code which will never be activated because it lies beneath a code diversion that always applies) would have caught it.

One former Apple staffer who worked on Mac OSX told the Guardian it’s “extremely unlikely, at least under normal circumstances” that the flaw was added maliciously. “There are very few people on any given team at Apple, and so getting changes lost in the shuffle would be difficult. The flip side is that there aren’t strong internal consistency/integrity checks on the codebase, so if someone were clever enough to subvert normal processes there would be easy ways in.”

But, the programmer added, “this change does not specifically stand out as malicious in nature.” The way it almost certainly happened is that it was a copy/paste error, or a merge issue (between two branches of code) that went unnoticed – “two similar changes could cause a conflict” (where the code has an illogical flow) “and in resolving this conflict an engineer might have made a mistake.”

What do programmers say?

One former Apple employee who worked on Mac OSX, including shipping updates and security updates, told the Guardian that Apple will be able to identify who did the code checkin which created the bug. “While source code management is on a team-by-team basis (there’s no company-wide policy), nearly every team uses some system (Git or SVN) that would be able to track commits [changes to code which are “committed” for use] and assign blame.”

The most likely explanation is that it occurred through the merging of two branches of code (where two or more people were working on the segment of code). Code merging is completely common in professional programming; reconciling conflicts between separate branches tends to be done by hand, using editors which will show up “diffs” (differences) between the old, new, and alternative new code.

Adam Langley, who works on security for Google’s Chrome browser (but hasn’t worked for Apple), says:

The fact that Apple is fixing the hole now suggests that it isn’t NSA-inspired. Though as John Gruber has pointed out, it’s perfectly possible that the NSA discovered this hole when iOS 6 was released and knew that it could exploit it.

One peculiar fact: if the NSA was aware of this security hole, it doesn’t seem to have told the US Department of Defense, which passed iOS 6 for use in government in May 2013.

When did Apple find the bug?

Early in January. On 8 January it contacted CVE, the Common Vulnerabilities and Errors database (used by all the major software developers) to reserve the bug number CVE 2014-1266 for the newly-discovered vulnerability, though CVE didn’t know what the vulnerability was.

Apple seems then to have begun working on the fix and how to roll it out. What’s odd is that despite finding the vulnerability then, it didn’t fix it in two beta versions of iOS 7.1 that were released after that time. One possibility – though the company won’t confirm this – is that it discovered the failure to authenticate the certificate in January, but took until now to narrow down the faulty piece of code – although given how quickly it took the rest of the web to do the same (a matter of a few hours) this seems unlikely.

Why didn’t Apple spot the bug sooner?

Its tests didn’t find it. The company won’t say what methods it uses – whether unit testing (in which individual chunks of code are tested individually) or regression testing where the new code is tested against known tests.
The former programmer there says “Apple does not have a strong culture of testing or test-driven development. Apple relies overly on ‘dogfooding’ [using its own products] for quality processes, which in security situations is not appropriate.
“From a good software engineering standpoint, this type of issue should have been found. It is shameful they are not running static code analysis at all (let alone automatically) on such important codebases.” The problem with static code analysis is that it can generate false positives – warnings about faults which aren’t – which led to several teams rejecting the idea, though it’s unclear whether the Security team was one of them.

How did Apple find the bug?

It seems to have been from a line-by-line review of code, almost certainly sparked by the revelations published by the Guardian of the NSA’s Prism efforts – and its other claims to have cracked SSL. At one point there was speculation that the code review was instigated by Kristin Paget, who was until recently in charge of Apple’s core OS X security, having joined in September 2012.

As she points out, Apple’s own security update system uses SSL – so might that be hacked by a “man in the middle” attack to plant malware?

Why didn’t Apple fix the bug for Mac OSX at the same time as it did for iOS?

It certainly should have, as Paget points out. Another former Apple staffer agrees; apparently Apple decided instead to roll out the fix for Mavericks as part of its 10.9.2 software update rather than as a separate security update (which it has done before). But other bugs were found in 10.9.2, delaying its release – and reducing the security of Mac users.

Have there been mistakes like this before?

Mistakes abound in software – and encryption mistakes are surprisingly easy to make. In May 2011, a security researcher pointed out that WhatsApp user accounts could be hijacked because they weren’t encrypted at all; until September 2011, there was a flaw in the same app which let people send forged messages pretending to be from anyone.

A common mistake is the use of default logins which are left active: millions of routers around the world have default user IDs and passwords (often “admin” and “admin”) which can be exploited by hackers.

A similar coding mistake bricked Microsoft’s Zune on the last day of 2008 – which, as luck would have it, was a leap year. There was a coding mistake in the software for the timer chip which wouldn’t allow it to display a date equivalent to the 366th day of the year.

And Microsoft had a long-running flaw in Windows 95 and Windows 98 which meant that if your computer had been running continuously for just under 50 days, it would suddenly hang – and you’d have to reboot it. Why? Because it measured “uptime” using a 32-bit register, which incremented every millisecond. After 2^32 milliseconds (aka 49 days and 17 hours), the register was all 1s – and the only way to reset it was turning the power off.

What lessons are there from this?

Not only that – but the flawed code has been both used and published for 18 months, and tested by a government security organisation which passed it for use. Software bugs can be pernicious – and they can lurk in the most essential areas. And even companies which have been writing software for decades can fall foul of them.

But the former staffer at Apple says that unless the company introduces better testing regimes – static code analysis, unit testing, regression testing – “I’m not surprised by this… it will only be a matter of time until another bomb like this hits.” The only – minimal – comfort: “I doubt it is malicious.”