About the security content of iOS 7.0.6

http://support.apple.com/kb/HT6147

by davepeck • 12 years ago

205 135 12 years ago

support.apple.com

Sounds like a classic Man-in-the-Middle (MITM) attack.

Just a guess, but from the short description I suspect if you have control over DHCP you can get iOS to use your proxy. From there you can use something like mitmproxy ( http://mitmproxy.org/) to forge SSL certificates on the fly and intercept and decrypt SSL traffic without any warnings showing up on the iOS device.

nwh3• 12 years ago

You can do that but you'll be throwing certificate errors everywhere if they're self signed. By the sounds of it this is a bypass or method of getting around the CA altogether.

chrismsnz• 12 years ago

Yes, normally certificate errors would be thrown.

In this case Apple is not performing the domain validity checks on the presented cert. This allows an attacker that is performing an mitm attack to present a valid cert for another domain and establish an SSL connection with the victim.

Fasebook• 12 years ago

lol oops

nwh3• 12 years ago

Does this contain patches for the jailbreak?

britta• 12 years ago

No, apparently. See https://twitter.com/winocm/status/436923366147375104 and https://twitter.com/winocm/status/436923608762695680 for a jailbreak developer saying that it doesn't seem to fix any jailbreak bugs. He's not one of the developers of the iOS 7 jailbreak, but he knows what he's talking about.

jayunit• 12 years ago

helper• 12 years ago

Wow, this sounds bad. It sure would be nice if Apple gave us a little bit more information, like when the bug was introduced and what exactly was not being verified. Until we get more information, you should assume the worst that all your IOS TLS traffic might be compromised.

Greenisus• 12 years ago

Does anyone know if this is an issue at the Foundation API level (affecting any apps using NSURLConnection, for example) or if it's a Safari issue?

acdha4• 12 years ago

It's actually the reverse: Safari at least performs additional checks and does not appear to be affected, which would explain why this wasn't noticed faster. The big question is whether those checks are specific to Safari or to a higher-level API which most Cocoa apps would use.

nekitamo• 12 years ago

Looks like they weren't checking the hostname in the certificate. This would allow anyone with a certificate signed by a trusted CA to do a MITM attack on iOS devices. Very very bad vulnerability.

mikeash2• 12 years ago

It seems to be a bit more than that, as I've verified that iOS 7.0.4 and Mac OS X 10.9.1 both refuse to connect to a server with a certificate for a different hostname. Sounds like verification is somehow different when connecting to a raw IP address. Safari treats that case differently, anyway: if I try to connect to a hostname that's different from what the certificate says, it simply refuses to establish the connection at all. If I try to connect to the raw IP address, it says the certificate is wrong, but gives me the choice to ignore the error and proceed anyway. Odd stuff.

MichaelGG• 12 years ago

Maybe due to lots of appliances that run HTTPS with a self-signed cert to "productname", but are often accessed via an IP?

makomk• 12 years ago

Looking at the code, this bug probably doesn't happen on connections which use TLS 1.2, which any properly configured server should support these days. (There's a seperate codepath for TLS 1.2 connections.) Note that this doesn't provide any protection against an attacker exploiting the vulnerability, since they get to choose what TLS version is used.

noclip3• 12 years ago

It's not just cURL. It's much bigger, and much worse.

http://pastebin.com/Yb6pUvr6

teraflop2• 12 years ago

I don't know what you think that pastebin shows, but that error is not specific to OS X or to ssl.apple.com. OpenSSL is failing to validate the server certificate because you forgot to specify the -CAfile option.

EDIT: I'm an idiot, see below.

noclip3• 12 years ago

Except it isn't failing.

croikle• 12 years ago

So, I'm not sure about that one. Apparently s_client ignores the error and completes the connection because it's intended to be used for debugging.

Currently the verify operation continues after errors so all the problems with a certificate chain can be seen. As a side effect the connection will never fail due to a server certificate verify failure.

https://www.openssl.org/docs/apps/s_client.html

https://www.mail-archive.com/openssl-users@openssl.org/msg71...

noclip3• 12 years ago

The s_client connection continues but should still report a verify error. On Linux:

http://pastebin.com/QWpSrR5p

tlrobinson• 12 years ago

Heh...

"congrats to the Apple iOS team on adding SSL/TLS hostname checking in their latest update! very cool feature."

https://twitter.com/will_sargent/status/436985812878491648

d05• 12 years ago

Comedic derision appreciated :)

However this is a pretty damn serious oversight.

I've just shut down my MacBook and picked up my ThinkPad.

homakov2• 12 years ago

Mac os is not vulnerable

thibaut_barrere• 12 years ago

If I believe [1], 4% of all the iOS devices are still on versions earlier than 6, and will not be patched to this specific issue. This is pretty severe. I wonder (but presume not) if Apple is going to issue patches for earlier versions.

[1] http://appleinsider.com/articles/13/12/31/ios-7-now-installe...

mikeash2• 12 years ago

iOS 6 gets a fix too: http://arstechnica.com/apple/2014/02/apple-releases-ios-7-0-...

Really old devices are probably out of luck, though. I think that would encompass the original iPhone, the 3G, the corresponding iPods Touch, and (probably most importantly) the first generation iPad. That's assuming, of course, that the bug is in iOS 4/5 in the first place, but if it dates back to iOS 6 I'd give good odds that it dates back farther still.

crishoj2• 12 years ago

If 96% of the installed base gets this patched more or less immediately, the situation is endlessly better than a similar situation would be for Android, given most manufacturers and operators' lack of interest in providing software updates.

shawn-butler• 12 years ago

Doesn't affect any app using SSL pinning.

I have been trying to work on an implementation of TACK to mitigate headaches involved in pinning. Wish I had more free time.

http://tack.io/index.html

theboss• 12 years ago

Yeah the biggest problem with mobile devices I see that desktop applications have less often is crypto problems..It will get better as the time goes on.

kryptiskt• 12 years ago

This is so bad that it is hard to imagine how it could have escaped notice until now, Apple really need to beef up their security competence. Lets hope that malevolent hackers were similarly asleep.

sneak• 12 years ago

Indeed. My first thought upon seeing this: "how in the FUCK did automated testing not catch this IMMEDIATELY!?"

Absolutely terrifying that crypto safety is such a low QA priority that something like this could ever leave the building.

giovannibajo1• 12 years ago

Because it's not a blatant regression, it's a complicate bug that requires a custom-patched TLS stack on the server to be explocited. As Adam Langley put it:

A test case could have caught this, but it's difficult because it's so deep into the handshake. One needs to write a completely separate TLS stack, with lots of options for sending invalid handshakes. In Chromium we have a patched version of TLSLite to do this sort of thing but I cannot recall that we have a test case for exactly this. (Sounds like I know what my Monday morning involves if not.)

newman314• 12 years ago

Same with openssh on OS X. For some unknown reason, Apple chose to disable ECDSA on ssh. You can generate the keys but you can't use them. Try it.

computer• 12 years ago

So, was this plus automatic updates over SSL one of the ways the NSA could access "any iOS device"?

hayksaakian• 12 years ago

Potentially. This exploit was known to apple for some period of time, if NSA has access to the internal apple bug tracker, then they could certainly exploit the bug.

hrrsn• 12 years ago

They'd also need access to Apple's private keys.

lawnchair_larry2• 12 years ago

No.

jtchang• 12 years ago

How do you not notice this? Maybe a lot of SSL interception is done with self signed certs and not ones that are signed by a valid CA?

lstamour2• 12 years ago

Odd. Apple updated iOS 7 and iOS 6 but didn't update Secure Transport in iOS 5? I wonder if the bug was introduced between iOS 5 and 6.

Background on Secure Transport:

"At the bottom of the TLS stack on both iOS and Mac OS X is a component known as Secure Transport. Secure Transport maintains a per-process TLS session cache. When you connect via TLS, the cache stores information about the TLS negotiation so that subsequent connections can connect more quickly. The on-the-wire mechanism is described at the link below.

http://en.wikipedia.org/wiki/Transport_Layer_Security#Resume...

"This presents some interesting gotchas, especially while you're debugging." More at: https://developer.apple.com/library/ios/samplecode/AdvancedU...

raquo• 12 years ago

Apple do not support two versions of iOS back. They expect you to upgrade to a newer, slower version of iOS every time it's released.

You won't be able to get the new iOS 6.1.6 on your iPhone unless it supports iOS 6 but not iOS 7, it is basically only for iPod 4th gen.

tricolon• 12 years ago

FWIW, the first time I went to https://notinthecert.imperialviolet.org in Mobile Safari on iOS 5.1.1, I got a "Cannot Verify Server Identity" error with Cancel, Details, and Continue buttons. After pressing Continue, it remembered my choice and did not alert me the second time.

SyneRyder• 12 years ago

Seems the bug was introduced in iOS 6. https://gotofail.com has been offering a test for the bug, and my iOS 5 devices pass the test.

crishoj2• 12 years ago

Bad as it may be, the fix Apple is pushing will reach roughly 95% of the installed base more or less immediately.

I can't help wonder how much worse a similar situation would be for the Android ecosystem, with the poor update track record of operators and OEMs.

UnoriginalGuy• 12 years ago

Google would just push an updated Chrome app which soft fixes it for many use-cases.

rodgerd• 12 years ago

Gruber, is that you?

lstamour2• 12 years ago

As it happens, Secure Transport (edit: on OS X) is open source. I just spent the last hour rummaging through source code ... It was later renamed to "libsecurity_ssl" when it landed on iOS. It's been around since OS X launched. They also have a folder with about four dozen regression tests and a test app, not that I've had the chance to inspect either that closely. The tarballs are spread across two folders in the tarballs index: Security (look for multi-MB file sizes) and libsecurity_ssl. The 5-digit numbers appear to be sequential revision IDs, any single-digit numbers seem historical. (E.g. libsecurity_ssl-6 is before libsecurity_ssl-10 rather than after libsecurity_ssl-55471.)

It appears they haven't posted newer source than this. The most recent timestamp I could find was Oct 11, 2013 in 55471, which corresponds to 7.0 and my 10.9 system has the same version number for Security.framework -- same bundle version of 55471 for 10.9.1 aka 13A581. Previous version numbers don't appear to be as well-maintained. I don't expect a newer release to be posted until the next OS X release, as the source was only published under 10.9, not iOS. Additionally, there's no mention of iOS 7 on http://www.opensource.apple.com/

I couldn't easily find the bug without more to go on, because the code is spread across a few components and really, I'm not an expert in TLS. It appears to have been largely unchanged from 2000-2006 or so. TLS 1.2 brought quite a few changes, but it was neat to browse through the lines of "FIXME" and "TODO" comments, as well as various diffs between releases. And neat to see how much code today still goes back to 1999-2001, sometimes all they did was add a 'k' in front of a few variable names or delete the line in the first README saying the server code wasn't tested against Windows ;-)

It sounds like when 10.9.2 is released, or at worst when 10.10 comes along, you'll see a new push of code to the opensource site. We can all diff 55471 against what comes next to see the changes. (If someone's already running 10.9.2 and its unaffected by the bug exhibited via curl, open /System/Library/Frameworks/Security.framework/Versions/Current/Resources/Info.plist and post the Bundle version.)

pencilo3• 12 years ago

Take a look at http://opensource.apple.com/source/Security/Security-55471/l...

specifically check the function SSLVerifySignedServerKeyExchange

I leave the joy of spotting it to you. It is obvious and if you know c you'll see it(You don't need any knowledge of crypto).

Someone3• 12 years ago

For the likely error I spot, you don't even need To know C. Anything remotely algol-like Will do.

I wonder whether the software from the guys at viva64.com would spot that.

mau• 12 years ago

Don't C compilers warn about code that is never executed?

I'm actually pretty impressed how this bug was not caught before. The compiler warning is just one thing that came to my mind but test coverage should have been the strongest hint. A linter could have also make the thing easier for a code review. Probably these parts of the code should have stricter coding guideline.

guycook• 12 years ago

Whoops. goto fail indeed

d05• 12 years ago

That's hilarious. Took me a while as I was looking for something more subtle. Thanks for the clues.

Another clue: indentation fail.

PhantomGremlin3• 12 years ago

People bitch about indentation in Python. But in this case it would have prevented the bug!

Of course Python doesn't even have a goto, so the code would have needed to be structured differently to start with.

If I were a betting man I'd wager that this bug wasn't really an accident. It would be really interesting to check commit logs to see the history.

PhantomGremlin3• 12 years ago

Here's a little bit of a conspiracy theory for you. There's an old saying: "there are no coincidences on Wall Street". Not with the amounts of money that are involved.

I think something similar should apply to critical security code. This reminds me of when someone tried to add the following to the Linux kernel:

if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) retval = -EINVAL;

Oops, is that "uid == 0", or is that "uid = 0"? Yet another "typo" that couldn't happen in Python.

alex12• 12 years ago

Here's a diff of that file from OS X 10.8.5 (Security-55179.13) to 10.9 (Security-55471): https://gist.github.com/alexyakoubian/9151610/revisions

Check line 631. Appears seemingly out of nowhere.

chaitanya• 12 years ago

(Spoiler) This is another reason why you should never use if statements without curly braces.

Thanks for the hint. It was amusing to spot the actual bug.

saalweachter• 12 years ago

Does anyone else look at this file and suddenly have a greater appreciation that their company uses a cumbersome, time-consuming code review process which enforces an annoying, rigid code style?

jamiesonbecker• 12 years ago

CloudFlare just opensourced "Red October", which implements the two-man rule for any cryptographic checkout, but it could be really good for code checkins to catch things like this.

http://blog.cloudflare.com/red-october-cloudflares-open-sour...

nikster• 12 years ago

Conspiracy theories aside, every programmer has probably made that mistake. The better ones learn to just avoid if statements without blocks ;)

But one thing that pisses me off is that they go and implement SSL and don't have any automated tests for it!!

For a company of Apple's size, that can only be called grossly negligent. There is no excuse. And they probably don't have any automated testing for most of their other code either.

What I would expect is that SSL code is tested with all the different of ways of spoofing a certificate. And that in an automated manner, on every build.

nymble• 12 years ago

This does not look like a merge error. The added line stands alone and it's very well located for an exploit.

aes• 12 years ago

Just from looking the code it seems pretty sloppy, not what I would expect from security sensitive code.

Mixed tabs and spaces, inconsistent indentation, two empty lines in a row, sometimes "if (...)" and sometimes "if(...)".

java123• 12 years ago

I wonder about the code style, too, but on a different level. You don't need curly braces (surely you should always use them) or whitespace sensitivity or source code indentation beautification if you use the appropriate programming technique for this situation. Such endless error checking followed by releasing of resources at the end is a case for try / catch / finally. I wonder when people start using decent languages for important coding.

rennison• 12 years ago

Damn what kind of half-assed developers do they have at Apple these days? They broke 2 of my (admittedly many) cardinal rules of C development: 1 - There is never ever a valid reason for using goto. It should not be part of the language. 2 - Always enclose script blocks in {} even if it's only a single line.

WaltSellers5• 12 years ago

Was there a more fundamental problem in the assumptions of the code?

The state of the operation is "success" (err==zero) until some step changes the state to "failure" (non-zero).

The state should be assumed to be "failure" until the last step changes it to "success".

pencilo3• 12 years ago

SSLVerifySignedServerKeyExchange in http://opensource.apple.com/source/Security/Security-55471/l...

If you want to see my favorite SSL bug ever.

jey2• 12 years ago

Oh god, that's horrifying. Get ready to check certificate validity, then report success before actually checking validity!

gojomo5• 12 years ago

Wow. Maybe the inconsistent indentation and brackets-optional formatting helped the bug both arrive and persist?

Perhaps a preferable practice for security-conscious code would be to only set a success value after all checks have passed, rather than trust intervening logic to reset a default-success value, to an error-value, before return.

hsivonen• 12 years ago

Are there any known software updaters that rely only on Secure Transport hostname checking for update authenticiity?

If you use NSS-based browsers exclusively on OS X, can you have been pwned via fake updates due to this bug?

richm44• 12 years ago

Adam Langley has written up the details of the issue here: https://www.imperialviolet.org/2014/02/22/applebug.html

Argorak• 12 years ago

Just to be clear:

/usr/bin/curl on Mavericks suffers from this problem:

    ~ /usr/bin/curl https://imperialviolet.org:1266
    If you can see this message then[...]

Keep that in mind when you download an installer using curl and pipe it to bash.

js2• 12 years ago

Unless curl uses Secure Transport on OS X, then it's a separate bug in curl/libcurl.

Edit: apparently curl does use Secure Transport on OS X as of 7.27:

http://curl.haxx.se/mail/lib-2012-06/0334.html

http://daniel.haxx.se/blog/2012/06/28/darwin-native-ssl-for-...

goobers• 12 years ago

Maybe Apple should stick to hardware.

Just sell me the beautiful hardware.

I'll manage installing an OS that's 1. audited by a community of volunteers I generally trust and 2. can be audited (read: modified) by me: I can compile it from scratch.

Apple's OS offerings provide neither 1 nor 2.

But, go figure, Apple's OS offerings are based off of OS code that is both 1 and 2.

Like a "Linux distro", Apple gives me a lot of stuff I do not want or need, and makes it very difficult if nt impossible to remove.

I want a very minimal BSD or Plan9 OS running on my Apple hardware.

And nothing more.

Hardware we purchase should come with full documentation for writing drivers.

If enough users demand this, maybe someday it will.

Adirael• 12 years ago

What's stopping you from installing FreeBSD or Apple's hardware?

Everything has bugs, community volunteers are not infallible. It's good to be able to audit the things you use, but most people can't or won't do it.

lisper2• 12 years ago

Since the source code is available, might it be possible to produce a hot patch to the binary so that those of us running Mavericks won't have to go through the next few days or weeks with our pants down? It would be a simple matter of finding the JMP instruction generated by the second GOTO and replacing it with no-ops. How hard could it be,at least for someone who actually knows their way around OS X binary file formats?

Someone3• 12 years ago

"It would be a simple matter of finding the JMP instruction generated by the second GOTO and replacing it with no-ops."

Only if they used a truly stupid compiler. Chances are the unreachable code behind it got optimized away.

lisper2• 12 years ago

Oh, right. (duh)

About the security content of iOS 7.0.6

Related Stories