Apple Fixes Dangerous SSL Authentication Flaw In iOS 101
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."
And thus is it delivered to all supported devices (Score:5, Informative)
The update is available to all supported devices (From the iPhone 3GS running 6.1.x and up).
Re: (Score:2)
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 (Score:4, Informative)
They also released 6.1.6 which patches this bug.
Re:And thus is it delivered to all supported devic (Score:4, Funny)
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. :-(
Re: (Score:3)
"Revealed: how US and UK spy agencies defeat internet privacy and security" (6 September 2013)
http://www.theguardian.com/wor... [theguardian.com]
How about OS X? (Score:5, Insightful)
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? (Score:5, Informative)
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: (Score:2)
What about 10.7.6, 10.8.3, etc.?
Re: (Score:2)
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: (Score:1)
Re: (Score:2)
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: (Score:1)
Running 10.9.2 here and gotofail.com continues to report the vulnerability ...
Re: (Score:2)
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: (Score:1)
You can prevent problems by not trusting SSL (Score:2)
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: (Score:3)
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 sca
Re: (Score:2)
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 (Score:1)
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
Re: (Score:2)
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.
Increase safety by avoiding proprietary software (Score:2, Insightful)
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 [slashdot.org] anytime Apple wants and the users have no idea which messages are being read. Whether anyone at Apple reads someone's iMessages is a detai
Re: (Score:3)
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... [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: (Score:2)
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.
Shipping Obviously Untested Code (Score:2)
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;
Details of bug (Score:5, Informative)
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: (Score:2)
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 (Score:4, Insightful)
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 (Score:2, Informative)
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 has
goto fail (Score:5, Informative)
in
http://opensource.apple.com/so... [apple.com]
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
Re: (Score:2, Interesting)
?! 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 (Score:1, Interesting)
Re: (Score:1)
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: (Score:2)
The source is available; how does "security through obscurity" apply at all?
Re: (Score:2)
Um, sure there is. Search for SSLHashSHA1.update; it's in the second group of them.
Re:goto fail (Score:5, Informative)
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... [imperialviolet.org]
Re: (Score:2, Funny)
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: (Score:1)
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 le
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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 [wikipedia.org] 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:warning about unreachable code (Score:4, Informative)
http://gcc.gnu.org/ml/gcc-help... [gnu.org]
Re: (Score:2)
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: (Score:2)
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: (Score:1)
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: (Score:2)
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 (Score:3)
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: (Score:3)
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 (Score:4, Insightful)
Dumb. We are in for more than that. It took a decade to get OpenSSL clean with many more eyes on it.
Re: (Score:1)
"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 c
Re: (Score:2)
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: (Score:1, Troll)
goto considered harmful.
Re: (Score:1)
The problem is single-line if bodies.
Or not using a tool that auto-indents the code.
Re: (Score:3)
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: (Score:1)
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.
Or they should just reject the goto command. This kind of issue could never have happened if the developer would have used properly structured code.
Re: (Score:1)
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 [koblents.com].
Re: (Score:2)
Re: (Score:2)
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 wi
Jailbreakers (Score:1)
Apple's strategy is to release an OS, wait a bit, then start releasing small incremental updates that ought to have been in the initial release in the first place. I suspect they do this on purpose in order to confound the jailbreakers.
Re: (Score:3)
Or are you of the opinion that it's possible to release such a massive amount of code totally bug-free?
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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!
Update their iOS devices to iOS 7.0.6 (Score:1)
And those that cant, send us 700 for a new device. And thanks for playing.
Re: (Score:3)
Or they could update to iOS 6.1.6 on their iPhone 3GS (previous versions of iOS did not have this bug)
Re: (Score:3)
Re: (Score:2)
They all suck. What is your point?
Goto? (Score:3)
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/ [xkcd.com]
5) GOTO 1
Re: (Score:1)
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: (Score:2)
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.
Exception handling (Score:2)
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.
That's one way to get everyone to update (Score:1)
Unlikely to effect me as I never use WiFi and MIM is a bit less likely over a cell connection.
OS X (Score:2)
I used the test site set up at https://www.imperialviolet.org... [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?