Apple Fixes Dangerous SSL Authentication Flaw In iOS

wiredmikey writes "Users of iOS devices will find themselves with a new software update to install, thanks to a certificate validation flaw in the mobile popular OS. While Apple provides very little information when disclosing security issues, the company said that an attacker with a 'privileged network position could capture or modify data in sessions protected by SSL/TLS.' 'While this flaw itself does not allow an attacker to compromise a vulnerable device, it is still a very serious threat to the privacy of users as it can be exploited through Man-in-the-Middle attack,' VUPEN's Chaouki Bekrar told SecurityWeek. For example, when connecting to an untrusted WiFi network, attackers could spy on user connections to websites and services that are supposed to be using encrypted communications, Bekrar said. Users should update their iOS devices to iOS 7.0.6 as soon as possible." Adds reader Trailrunner7: "The wording of the description is interesting, as it suggests that the proper certificate-validation checks were in place at some point in iOS but were later removed somehow. The effect of an exploit against this vulnerability would be for an attacker with a man-in-the-middle position on the victim's network would be able to read supposedly secure communications. It's not clear when the vulnerability was introduced, but the CVE entry for the bug was reserved on Jan. 8."

Comments

And thus is it delivered to all supported devices

[Rosyna]

The update is available to all supported devices (From the iPhone 3GS running 6.1.x and up).

How about OS X?

[rvw]

I heard OSX has the same problem.

@Apple: Admit that it exists (plus give advice how to prevent problems) or let us know that OSX is safe.

Re:How about OS X?

[berj]

Yes. 10.9.1 has this problem (not sure about earlier versions). 10.9.2, which is in beta, patches the problem. Should be released soon.

Re:How about OS X?

[antdude]

What about 10.7.6, 10.8.3, etc.?

Re:How about OS X?

[berj]

I've not read that they exhibit this bug. I've only seen 10.9.0 and 10.9.1 mentioned.

I don't have any non-mavericks machines anymore otherwise I'd test it.

Re:How about OS X?

[Trillan]

10.7 probably isn't vulnerable, as it predates iOS 5 (which doesn't have this flaw).

If 10.8 is vulnerable, the suggested upgrade would be 10.9.3 anyway. (10.9 has the same requirements as 10.8, and is a free upgrade.)

I would like to see an article that explains which versions are vulnerable, however.

Re:How about OS X?

[frankns]

Running 10.9.2 here and gotofail.com continues to report the vulnerability ...

Re:How about OS X?

[Trillan]

There's no contradiction there. You are running a seed of 10.9.2, not 10.9.2.

I'm more curious if Apple will put out a fix BEFORE 10.9.2 ships; rumours still peg 10.9.2. a few weeks away.

Re:How about OS X?

[dxdt]

Which version of 10.9.2 is fixing this major security bug?

Re:How about OS X?

[dxdt]

Checked: 10.8 doesn't exhibit this SSL security bug.

Re:And thus is it delivered to all supported devic

[AmiMoJo]

How does that work? It seems that you need to get iOS 7 to get the patch. Did they back-port it to iOS 6? Or do they have some mechanism like Google does for updating older versions via their app store?

Re:And thus is it delivered to all supported devic

[berj]

They also released 6.1.6 which patches this bug.

Details of bug

[DrDevil]

The bug is that the cn hostname from the certificate is not verified. So it's possible to use your own website SSL cert as a cert for any other site and Apple devices will accept it no question. Of course, to exploit, you'd need to modify a tool like webmitm to serve a fixed certificate.

Very very dangerous, seems to be a result of switching away from OpenSSL although details are still flaky.

Re:Details of bug

[CODiNE]

I was curious about Apple deprecating OpenSSL so went looking into it.

Apparently OpenSSL doesn't keep a stable API between versions so developers should either static link it (ensuring eventual security problems if they are shipping out of date versions) or use something else if dynamic linking since Apples software updates would update OpenSSL and break apps using it.

Re:Details of bug

[am 2k]

Apple never "switched away" from openssl, they shipped their own implementation with the very first version of Mac OS X. They only packaged openssl with the system for other apps to use. I actually rewrote the XMPP encryption stuff in Adium to use the security framework instead of openssl way back in 2007, since that allowed me to use the built-in system dialogs for presenting certificates.

Re: Details of bug

[Anonymous Coward]

That's not the bug at all. It has nothing to do with hostname verification whatsoever. In fact, traditional RSA+AES CBC connections are not affected at all. Only ephemeral, or so-called "perfect forward secrecy" key exchanges are affected.

However because cipher choice and handshake choice are left to the server (picking from a set that the client advertises) in the protocol, a malicious server can always pick the vulnerable key exchange and exploit it.

The precise bug is subtle. The failure to verify the hashed signature of the ephemeral key exchange means that the server can present any valid public cert without ever knowing the private key for the cert.

goto fail

[tero]

in
http://opensource.apple.com/so...

  if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
                goto fail;
                goto fail;

Re:goto fail

[Anonymous Coward]

?! Any decent compiler would throw up a warning for unreachable code. I know that the whole "many eyes" thing is a miss and an audit of any open source code will usually pick up trivial problems, but that one doesn't even make any sense unless Apple coding practices are so poor that no sensible person would touch their products.

Re: goto fail

[Goldfish1974]

That's why sensible people use Android...at least you know how its broken...better than Apples rose colored glasses...

Re:goto fail

[tero]

Yeah, you'd think a compiler should have caught that.. but neither GCC or Xcode seems to do that..

Adam Langley has a great blog post dissecting this:
https://www.imperialviolet.org...

Re: goto fail

[ugen]

Curious. This would seem to result in a failure every time. Without reading the code further - how could auth ever succeed? Or did it ignore the failure return code and relied on hash update results anyway?

Switching away from OpenSSL that is widely used and audited for generations of releases to homegrown crypto is a mistake on Apples part. This is most certainly not the last security flaw in their code we will see.

Re: goto fail

[tero]

Yeah, the hash update succeeds, so err contains successful value when it jumps to the end. It never reaches the dead part where it updates.

Re: goto fail

[Anonymous Coward]

"goto fail" is misleading, imho. It's more "goto finally". After cleaning up, the function returns the current value of err, which would after the unconditional "goto fail" be 0, i.e. success.

Yes. Writing code is easy (I do it every day). Writing security-related code is moderately easy if you're mathematically minded. Writing robust security-related code is fucking hard - not just because of all the implementation details, but because humans repeatedly make schoolboy errors. It's just how we are. If your code isn't being audited by multiple people on every changeset, you're wasting your time doing anything more than hobby projects. And Apple's iOS is arguably not a hobby project.

Re: goto fail

[ugen]

Dumb. We are in for more than that. It took a decade to get OpenSSL clean with many more eyes on it.

Re: goto fail

[amaurea]

The return code from the function is "err", which is the result of the last test that was done inside the function. The second goto is only reached if err is 0 (success), so at that point the function returns success.

Re:goto fail

[AmiMoJo]

It's similar to some of the bugs that the NSA/GCHQ have inserted in the past. Knowing this we should really make compilers detect this kind of error.

Re:goto fail

[ChunderDownunder]

Coding standards often specify pedantic use of superfluous braces, even for single line clauses, e.g.

if (condition) { // single line here
}

But clearly the folks at Apple know better. :-(

Re:goto fail

[arglebargle_xiv]

Yeah, you'd think a compiler should have caught that.. but neither GCC or Xcode seems to do that.

Visual Studio will detect and complain about this. So all Apple would need to do is switch to Microsoft Vis.... oh. Damn.

Re:goto fail

[BitZtream]

So does Clang in current versions of Xcode. No one uses GCC on Apple anymore so its really irrelevant. We've moved on to compilers that don't suck ass. GCC remains for fanboys but thats about it.

The person you're replying to hasn't used Xcode for a very long time apparently.

Clang bitches about any silly coding mistake pretty much, not just unreachable code due to a return or some sort of jmp over code, but also warnings about things such as not catching every case in a switch on an enum.

I'd give up my left testicle if Apple would magically port and start using Visual Studio in OSX though. I can't stand dealing with Windows anymore, but god I long for an IDE that doesn't suck ass.

Re:goto fail

[BitZtream]

There is no unreachable code of goto fail jumps to the right place.

If you look at the actual source and think a moment, its pretty clear and isn't entirely illogical, though I admit, it is broken.

The snippet you are replying too looks stupid standing on its own, in context it doesn't stand out nearly as well, and there is absolutely no way you can tell by that snippet if there is any unreachable code or not, you have no idea from the snippet whats after those gotos or what those gotos do.

Re: goto fail

[BitZtream]

Uhm ... so you don't know whats broken when you've been given a link to the source in question? But on Android you magically do?

So are you just retarded and only can read source for Android and no other purpose or just too stupid to realize that the source code in question here is VERY open ... and fucking linked a few posts above your for fucks sake.

Fucking ignorant fanboy won't even read the fucking web page your on.

Re:goto fail

[BitZtream]

The linked file uses both braces for single line ifs and without braces for single line IF's ... that is a really bad sign as a developer in my opinion. That means they aren't enforcing style guidelines and that makes code a fuckton harder to read. I can adapt to either style fairly easy, but when you mix it my mind gets wonky, my mind tends to find it ambiguous too!

Re:goto fail

[Antique Geekmeister]

As does gcc with the right flags, which detect "unreachable code". That can often generate a storm of warnings that require a great deal of additional time to sort through and resolve, and can be different depending on compile time definitions. So it's not often used.

Re:goto fail

[am 2k]

No one uses GCC on Apple anymore so its really irrelevant. We've moved on to compilers that don't suck ass. GCC remains for fanboys but thats about it.

Tell that to certain tools coming from Linux that rely on STL interas only available in the GCC version of STL...

I'd give up my left testicle if Apple would magically port and start using Visual Studio in OSX though. I can't stand dealing with Windows anymore, but god I long for an IDE that doesn't suck ass.

I know quite a few Mac developers that say exactly the opposite ("I'd port my Mac app to Windows, if there was an IDE that didn't suck ass...").

Re:goto fail

[kybred]

The lines of code immediately after the second 'goto fail;' up to the 'fail' label are unreachable. There is no label or closing brace after the second goto fail, so how would it get executed?

Re:goto fail

[bgarcia]

I wouldn't blame the goto here.
The problem is single-line if bodies.
Or not using a tool that auto-indents the code.

Re:goto fail

[arglebargle_xiv]

As does gcc with the right flags, which detect "unreachable code".

No it doesn't. -Wunreachable-code is accepted as a compiler option, but it does nothing while making you think it's actually doing what it claims to.

(Yet another of the many reasons why the sooner clang/LLVM kills gcc, the better).

Re:goto fail

[arglebargle_xiv]

Goto fail. Go directly to fail. Do not pass the signature check. Do not collect an error status.

Re:goto fail

[tlhIngan]

in
http://opensource.apple.com/so...

    if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
                                goto fail;
                                goto fail;

That looks to be the result of a bad patch - anyone who uses git probably can see what happens if you don't rebase patches properly - you end up with patches that apply in very strange and very wierd ways. Especially if the patch in question contains a lot of repeated statements such that the context diff doesn't contain enough context.

Either that, or it was a patch that was being applied manually (because it wasn't rebased properly) and someone forgot to delete an extra line

(It's great fun when code gets so similar that the patch really can apply almost anywhere - it's resulted in some very strange device trees after patching the Linux kernel).

?! Any decent compiler would throw up a warning for unreachable code. I know that the whole "many eyes" thing is a miss and an audit of any open source code will usually pick up trivial problems, but that one doesn't even make any sense unless Apple coding practices are so poor that no sensible person would touch their products.

The problem is it's really easy to miss warnings when a build is in progress - the compiler may produce a ton of warnings, but it's all intermixed and interspersed during the build (especially during multicore builds) that it's hard to see or even find.

Especially in builds for a large system - people are likely to just kick off the main build and miss warnings on the bit that they fixed.

Heck, I do that when fixing code in Android - I'd fix a bug, kick off the build and it'll scroll by way too fast. Even finding an error can be a chore because of all the output - it can be hundreds of lines behind the prompt.

Re: goto fail

[Trillan]

Um, sure there is. Search for SSLHashSHA1.update; it's in the second group of them.

Re: goto fail

[Trillan]

The source is available; how does "security through obscurity" apply at all?

Re:goto fail

[Jackmn]

Using goto for error handling in C is a well-established idiom, and is often the best option available. The alternatives either involve deeply nested if statements, or duplicated cleanup code.

For example, this pattern is used quite heavily in the Linux kernel. Linus (and a few others) had had something to say on this matter.

Re: And thus is it delivered to all supported devi

[AHuxley]

The AC seems to be hoping we have all forgotten
"Revealed: how US and UK spy agencies defeat internet privacy and security" (6 September 2013)
http://www.theguardian.com/wor...

Re:warning about unreachable code

[eddy]

Sorry, it's not there. It's silently ignored, which is the WORST POSSIBLE SOLUTION to the problem. Ugh.

The -Wunreachable-code has been removed, because it was unstable: it relied on the optimizer, and so different versions of gcc would warn about different code. The compiler still accepts and ignores the command line option so that existing Makefiles are not broken. In some future release the option will be removed entirely.

http://gcc.gnu.org/ml/gcc-help...

Re:Jailbreakers

[MikeMo]

Apple's strategy is to test, test, test and then test the best they can, release multiple beta versions to developers for testing, take a very long time to release new versions, and then patch the missed bugs that show up as fast as they can. Pretty much the way any professional software house does business.

Or are you of the opinion that it's possible to release such a massive amount of code totally bug-free?

Re:Jailbreakers

[jo7hs2]

That's a little paranoid even for a post about Apple.

You can prevent problems by not trusting SSL

[Marrow]

Really, why would you trust a system where someone you dont know or trust is in charge of the private keys for the encryption?

Re:You can prevent problems by not trusting SSL

[dkf]

Really, why would you trust a system where someone you dont know or trust is in charge of the private keys for the encryption?

Failing to secure your connections is just wilfully stupid. SSL is the best option we've got to avoid a whole range of attacks (it's far easier than the alternatives) but it does require correct implementations and careful selection of who to trust; SSL itself does not specify who to trust (and how can it? It's just a technical protocol for how to establish a secure channel over an insecure connection, typically implemented with TCP/IP).

Explicitly listing who to trust is best, but it's extremely hard to scale up (since you have to pre-share the keys). A web-of-trust scales better, but once someone makes a mistake (easily done) it all crumbles. Using a certificate authority scales much better, and isn't quite as brittle as a WoT, but it does rely on the CAs (especially the root CAs; non-roots are easier to discipline) being very highly trustworthy. Commercial pressures are unlikely to make limiting the scope of domains that any CA can issue for practical (and in any case, certificates are not tied to domains in general; that's a feature of some particular types of certificates only).

Every time someone suggests "oh we can't trust SSL" it is invariably because they don't know what it does and doesn't do, and because they think that there's only one kind of threat. That's incredibly wrong-headed and foolish.

Re:You can prevent problems by not trusting SSL

[Marrow]

I am not saying we should run unsecured connections or that there is a single type of threat. And your post ends up sounding like a bunch of excuses as to why we have no choice but to trust something like SSL because its the only thing we got and we are stuck with it.

Re: You can prevent problems by not trusting SSL

[Anonymous Coward]

Your comment demonstrates a total lack of understanding of SSL.

Private keys are always ONLY in the hands of the communicating parties. You never transmit your private key to anyone, if you're doing things right.

Third party Cert Authorities sign a certificate fingerprint. They establish a "trust chain" where if you trust the CA to do verification of identity, then you can trust the identity of the signed certs. The CA never sees the private key to do this trust certification.

If you don't trust CAs, skip all that. Sign the certificate yourself and SSL as a protocol still works fine for encryption. It just no longer guarantees identity of the endpoint without additional out-of-band checks by your application.

Re:You can prevent problems by not trusting SSL

[amorsen]

No one you don't know or trust is in charge of the private keys for the encryption. Except if you don't trust the party you are talking to, in which case you are looking for DRM, not encryption.

Goto?

[BlackPignouf]

1) I haven't seen GOTO statements since my GWBASIC days, and I've surely never seen this many.
2) I really like one-liners for if statements in Ruby: "do_this if x==1"
3) Two-liners for C if statements without curly braces feel wrong, are dangerous and hard to read
4) http://xkcd.com/292/
5) GOTO 1

Re:Goto?

[Anonymous Coward]

1) I haven't seen GOTO statements since my GWBASIC days, and I've surely never seen this many.

Then you don't write much low level C code. Error handling in C is possibly the only place where goto statements are useful, because the alternative is deeply nested if statements. Other languages solve it by using try-catch-finally blocks.

Re:Goto?

[Barlo_Mung_42]

I've seen them used in this case where you would otherwise need an ugly nested if. Two in a row though? That seems decadently excessive.

That's one way to get everyone to update

[koan]

Unlikely to effect me as I never use WiFi and MIM is a bit less likely over a cell connection.

Re:Update their iOS devices to iOS 7.0.6

[Rosyna]

Or they could update to iOS 6.1.6 on their iPhone 3GS (previous versions of iOS did not have this bug)

Re:Update their iOS devices to iOS 7.0.6

[immaterial]

Really... Five hours after the *first post* already shot down this claim?

Increase safety by avoiding proprietary software

[jbn-o]

The software Apple distributes to users is proprietary, even if part of that software is built from free software. Proprietary software is never safe for users. Its safety is for the proprietor—what the program allows the proprietor to do to the users.

Apparently memories around here are so short people can't remember when researchers showed Apple can read iMessages anytime Apple wants and the users have no idea which messages are being read. Whether anyone at Apple reads someone's iMessages is a detail so long as Apple can read any iMessage they choose. The same applies to any proprietor for any software which doesn't respect your software freedom. You avoid these problems by avoiding proprietary software.

OS X

[oDDmON oUT]

I used the test site set up at https://www.imperialviolet.org... with a X.6.8 rig using both Safari and FF. It passed with flying colors.

Does this mean earlier versions of OS X don't have the bug?

Re:What about iOS 6?

[ciurana]

Apple also released iOS 6.1.6 in response to the bug.

If your iPhone is jailbroken, there's ongoing discussion to release a patch via Cydia and Evasi0n.

Cheers!

Re:Increase safety by avoiding proprietary softwar

[93 Escort Wagon]

Given this bug exists in published open source code, I'm not sure how your point is relevant to this particular issue.

https://www.imperialviolet.org...

Open source code is not a panacea. Have you not been paying attention to the number of RHEL kernel updates (to pick one example) released in 2014?

Re:Jailbreakers

[93 Escort Wagon]

The problem is - and we've seen this before - Apple is unnecessarily reinventing the wheel in certain cases. It's the same general problem Microsoft ran into when they decided they wanted to develop their own completely in-house tcp stack earlier this millennium - you're starting from scratch, and you sometimes end up with code that exposes bugs that were patched in the time-tested tools years (or even decades) earlier. Or, as in this case, there are fewer cumulative sets of eyes reviewing your open source code.

It's also why rolling your own crypto is probably not a smart practice, even with the NSA's traitorous actions. If you're truly smart enough to do that, you're still better served looking for the problems in existing ciphers.

Re:And thus is it delivered to all supported devic

[Anonymous Brave Guy]

Unfortunately, Apple seem to have abandoned iOS 5 support already.

iOS 6 isn't even 18 months old yet and was their Windows Vista, so a lot of people didn't upgrade. iOS 7 isn't even 6 months old, had security problems of its own at launch, and runs like a limping dog on some very popular devices still in widespread use, so a lot of people didn't upgrade to that either.

The vulnerability here was caused by a rookie error that could easily have been found and fixed by following any one of several best practices in their software development process, and for something security-related they should have been following all of them.

This is a very poor show from Apple on all counts. :-(

Shipping Obviously Untested Code

[billstewart]

It's not like nobody's ever declared they're done and shipped code without testing it first, or without fixing all the bugs they found, but they obviously didn't test this one.

Fail: goto fail;

Re:Increase safety by avoiding proprietary softwar

[jbn-o]

The point you fail to understand is that with software that respects a user's freedom, one doesn't need to wait for someone else to fix the bug for them and then hope that bug actually gets fixed when the ostensible fix is released. Users running nothing but free software have options to fix any bug and verify that fix which proprietary software disallows.

The rest of your statement is a form of false dichotomy—arguing from perfection. I never said anything was perfect.

Re:Update their iOS devices to iOS 7.0.6

[nurb432]

They all suck. What is your point?

Exception handling

[mveloso]

This is exactly when you use gotos in real life. If you look at low-level implementations it's easier to use goto and hit cleanup code than it is to unwind a ridiculous amount of crap.

Also, it's funny - Apple's style guidelines used to require curly braces around all statements in the if, even if it's a one liner. Guess those unix guys have subverted the paradigm.