goto fail;
February 22, 2014 8:11 AM Subscribe
Yesterday, Feb 21, Apple computer released a security patch with a vague description of SSL fixes. It turns out that it's quite a bug which would trivially allow Man in the Middle attacks for assumed-secure connections via SSL. Folks dug into the code and found the code resulting in the bug. If this affects you and your devices, you might want to go upgrade.
Sounds like the affected devices are: iPhone 4 and later, iPod touch (5th generation), iPad 2 and later.
(correct me if I'm wrong on that)
posted by LobsterMitten at 8:18 AM on February 22, 2014
(correct me if I'm wrong on that)
posted by LobsterMitten at 8:18 AM on February 22, 2014
Kind of glad now that I've been using my iPad exclusively to play Out There for the last few days...
posted by running order squabble fest at 8:21 AM on February 22, 2014
posted by running order squabble fest at 8:21 AM on February 22, 2014
But but but mah Jailbreaks!
Wait nevermind, it's Jailbreakable, but evasi0n needs to be manually edited to support the version number. Possible new evasi0n version in a few days?
https://twitter.com/winocm/status/437255940669067264
Wait nevermind, it's Jailbreakable, but evasi0n needs to be manually edited to support the version number. Possible new evasi0n version in a few days?
https://twitter.com/winocm/status/437255940669067264
@acfrazier Yes. Hex edit evasi0n to add 7.0.6 support. ;Pposted by wcfields at 8:25 AM on February 22, 2014 [1 favorite]
From the link to Adam Langley's blog:
posted by caaaaaam at 8:28 AM on February 22, 2014 [4 favorites]
I think OS X (at least 10.9.1) is still vulnerable, and I see no updates currently available. Pretty scary stuff.
"I coded up a very quick test site at https://www.imperialviolet.org:1266. Note the port number (which is the CVE number), the normal site is running on port 443 and that is expected to work. On port 1266 the server is sending the same certificates but signing with a completely different key. If you can load an HTTPS site on port 1266 then you have this bug."
posted by caaaaaam at 8:28 AM on February 22, 2014 [4 favorites]
On OSX, I believe that non-safari browsers (like firefox) will do the right thing as they do their own cert checking.
I also note that "CVE-2014-1266" was allocated on 1/8 but hasn't actually been updated over at cve.mitre.org.
posted by rmd1023 at 8:31 AM on February 22, 2014 [3 favorites]
I also note that "CVE-2014-1266" was allocated on 1/8 but hasn't actually been updated over at cve.mitre.org.
posted by rmd1023 at 8:31 AM on February 22, 2014 [3 favorites]
And thus the Internet is taught, once again, why goto's are evil, and not compiling with max warning levels set and paid attention to is bad coding practice.
(seriously, this code will generate "never executed" warnings for the stuff past the extra goto).
posted by Old'n'Busted at 8:32 AM on February 22, 2014 [5 favorites]
(seriously, this code will generate "never executed" warnings for the stuff past the extra goto).
posted by Old'n'Busted at 8:32 AM on February 22, 2014 [5 favorites]
Safari, OS X 10.8.5, test site fails to load. Maybe it's specific to Mavericks?
posted by indubitable at 8:32 AM on February 22, 2014
posted by indubitable at 8:32 AM on February 22, 2014
On OSX, I believe that non-safari browsers (like firefox) will do the right thing as they do their own cert checking.
Yeah, sorry, I should have clarified. To further quote:
"It affects anything that uses SecureTransport, which is most software on those platforms although not Chrome and Firefox, which both use NSS for SSL/TLS."
posted by caaaaaam at 8:35 AM on February 22, 2014 [1 favorite]
Yeah, sorry, I should have clarified. To further quote:
"It affects anything that uses SecureTransport, which is most software on those platforms although not Chrome and Firefox, which both use NSS for SSL/TLS."
posted by caaaaaam at 8:35 AM on February 22, 2014 [1 favorite]
indubitable: when i tried it 20 mins ago it was down which is another unrelated error.
posted by 3mendo at 8:38 AM on February 22, 2014
posted by 3mendo at 8:38 AM on February 22, 2014
Well, Safari's error message is kind of vague, in that it just says that it couldn't establish a secure connection, but Firefox definitely issues an "SSL IS FUCKED!!!" kind of programmer gibberish message. So the site's up.
posted by indubitable at 8:42 AM on February 22, 2014
posted by indubitable at 8:42 AM on February 22, 2014
So, if iOS/OS X can't validate the ssl cert, how does it know it is downloading the update from Apple's servers?
posted by Freen at 8:52 AM on February 22, 2014 [6 favorites]
posted by Freen at 8:52 AM on February 22, 2014 [6 favorites]
seriously, this code will generate "never executed" warnings for the stuff past the extra goto
-Wall -Wextra all the way here -- and -Werror if you can get away with it, to force attention to warnings.
But actually the ImperialViolet post notes, with some surprise, that -Wall doesn't warn on similar code:
posted by We had a deal, Kyle at 8:53 AM on February 22, 2014 [25 favorites]
-Wall -Wextra all the way here -- and -Werror if you can get away with it, to force attention to warnings.
But actually the ImperialViolet post notes, with some surprise, that -Wall doesn't warn on similar code:
If I compile with -Wall (enable all warnings), neither GCC 4.8.2 or Clang 3.3 from Xcode make a peep about the dead code. That's surprising to me. A better warning could have stopped this but perhaps the false positive rate is too high over real codebases? (Thanks to Peter Nelson for pointing out the Clang does have -Wunreachable-code to warn about this, but it's not in -Wall.)IMHO the evil is less the gotos, more the unbraced ifs. The indentation of the gotos implies promises that the compiler won't keep. If the statement won't fit on the same line as the if: open a pair of braces.
posted by We had a deal, Kyle at 8:53 AM on February 22, 2014 [25 favorites]
And someone set up https://gotofail.com to test as well.
posted by These Premises Are Alarmed at 8:57 AM on February 22, 2014 [2 favorites]
posted by These Premises Are Alarmed at 8:57 AM on February 22, 2014 [2 favorites]
I don't own any Apple devices but my dude does. Am I correct in thinking all he needs to do is download the patch from Apple and all will be well?
posted by feckless fecal fear mongering at 8:59 AM on February 22, 2014
posted by feckless fecal fear mongering at 8:59 AM on February 22, 2014
I don't own any Apple devices but my dude does. Am I correct in thinking all he needs to do is download the patch from Apple and all will be well?
Yep. Easy.
posted by The Michael The at 9:23 AM on February 22, 2014
Yep. Easy.
posted by The Michael The at 9:23 AM on February 22, 2014
Are these patches only for the latest iOS? I have an iPhone 4 running iOS6 because I don't want iOS7 to turn it to frozen molasses, and I have a first gen iPad running iOS5 (end of the line for updates there).
Does this mean I have to update my phone to iOS7, then patch?
posted by maudlin at 9:29 AM on February 22, 2014 [1 favorite]
Does this mean I have to update my phone to iOS7, then patch?
posted by maudlin at 9:29 AM on February 22, 2014 [1 favorite]
Finally, a valid excuse I can use to drag my wife's IPad 2 into the iOS 7 era (she hates the new UI, so we've been wrestling over this for months!).
posted by valkane at 9:30 AM on February 22, 2014
posted by valkane at 9:30 AM on February 22, 2014
The worst part is that there's no OS X fix available yet. (At least that I can find?)
If you're concerned, use Chrome or Safari, webmail instead of Mail.app, or launch a virtual machine.
Unbraced if, or even worse unbraced for loops, are just unforgivable. They were a mistake in the design of the C language, as they complicate the compiler grammar. Just a terrible idea all around.
posted by Llama-Lime at 9:30 AM on February 22, 2014 [3 favorites]
If you're concerned, use Chrome or Safari, webmail instead of Mail.app, or launch a virtual machine.
Unbraced if, or even worse unbraced for loops, are just unforgivable. They were a mistake in the design of the C language, as they complicate the compiler grammar. Just a terrible idea all around.
posted by Llama-Lime at 9:30 AM on February 22, 2014 [3 favorites]
Pretty irresponsible for Apple to drop this on a Friday and not fix the vulnerable code in OSX at the same time. At least my first gen iPad isn't effected...
posted by These Premises Are Alarmed at 9:32 AM on February 22, 2014
posted by These Premises Are Alarmed at 9:32 AM on February 22, 2014
Are these patches only for the latest iOS? I have an iPhone 4 running iOS6 because I don't want iOS7 to turn it to frozen molasses, and I have a first gen iPad running iOS5 (end of the line for updates there).
Even OSX 10.8 seems to be unaffected, so I'm guessing older ios versions may be fine; just try loading the test page linked above and see what happens.
posted by advil at 9:33 AM on February 22, 2014
Even OSX 10.8 seems to be unaffected, so I'm guessing older ios versions may be fine; just try loading the test page linked above and see what happens.
posted by advil at 9:33 AM on February 22, 2014
Don't worry. The security update used to patch Apple's iOS SSL authentication flaw will be delivered to you securely via a SSL connection.-@csoghoian
posted by brokkr at 9:33 AM on February 22, 2014 [7 favorites]
I also have an iPhone 4 running iOS6, and the testpage at gotofail.com declares my phone vulnerable. I was really hoping to avoid the upgrade to iOS7...
posted by pemberkins at 9:37 AM on February 22, 2014 [1 favorite]
posted by pemberkins at 9:37 AM on February 22, 2014 [1 favorite]
This bug is serious and dangerous. Upgrade iOS immediately. You're screwed if your Mac is on Mavericks; Apple has published the exploit but not the fix. Avoiding Safari will help a lot, but many MacOS applications rely on the broken library. Hopefully they'll fix this faster than the six weeks it took them to fix Java; that delay led to the birth of the Flashback botnet.
What's really alarming about this bug is how bad Apple's security engineering is.
A code review would have caught this bug.
A sensible C style guide would have prevented this bug.
Lint would have caught this bug.
A static analyzer would have caught this bug.
A unit test would have caught this bug.
An integration test would have caught this bug.
Apparently Apple is following none of these established engineering practices. That's bad in general, but for a critical security library it's outright negligence.
posted by Nelson at 9:38 AM on February 22, 2014 [60 favorites]
What's really alarming about this bug is how bad Apple's security engineering is.
A code review would have caught this bug.
A sensible C style guide would have prevented this bug.
Lint would have caught this bug.
A static analyzer would have caught this bug.
A unit test would have caught this bug.
An integration test would have caught this bug.
Apparently Apple is following none of these established engineering practices. That's bad in general, but for a critical security library it's outright negligence.
posted by Nelson at 9:38 AM on February 22, 2014 [60 favorites]
Are these patches only for the latest iOS? I have an iPhone 4 running iOS6 because I don't want iOS7 to turn it to frozen molasses, and I have a first gen iPad running iOS5 (end of the line for updates there).
From The Register article in the FPP:
Versions 7.0.6 and 6.1.6, available now for download, fixes a vulnerability that could allow "an attacker with a privileged network position" to "capture or modify data in sessions protected by SSL/TLS," according to the iPhone maker.
So I read that as iOS 6 is vulnerable as well. HOWEVER, when I updated my wife's iPad running 6, it jumped straight to 7 (through iTunes), with no option for the 6.1.6.
The wife is also using an iPhone 4, and it's not that slow using 7. YMMV.
posted by valkane at 9:39 AM on February 22, 2014
From The Register article in the FPP:
Versions 7.0.6 and 6.1.6, available now for download, fixes a vulnerability that could allow "an attacker with a privileged network position" to "capture or modify data in sessions protected by SSL/TLS," according to the iPhone maker.
So I read that as iOS 6 is vulnerable as well. HOWEVER, when I updated my wife's iPad running 6, it jumped straight to 7 (through iTunes), with no option for the 6.1.6.
The wife is also using an iPhone 4, and it's not that slow using 7. YMMV.
posted by valkane at 9:39 AM on February 22, 2014
If you're concerned, use Chrome or Safari
That should be Chrome or FIREFOX; Safari is definitely vulnerable.
posted by Ian A.T. at 9:43 AM on February 22, 2014 [3 favorites]
That should be Chrome or FIREFOX; Safari is definitely vulnerable.
posted by Ian A.T. at 9:43 AM on February 22, 2014 [3 favorites]
Yes - I just tested this for my 10.9.1 laptop, Safari is vulnerable but Chrome is ok.
posted by LobsterMitten at 9:46 AM on February 22, 2014 [1 favorite]
posted by LobsterMitten at 9:46 AM on February 22, 2014 [1 favorite]
I've got a Macbook Pro running 10.8.5 and a Macbook with 10.7.5. On both, trying https://gotofail.com in Safari returns "Your browser aborted loading the test image upon seeing an invalid ServerKeyExchange message. This means your browser is not vulnerable to the bug, however if you're on an Apple device make sure you check with Safari." So does this mean the bug only affects Mavericks on laptops/Macs? Thanks.
posted by miomiomio at 9:47 AM on February 22, 2014
posted by miomiomio at 9:47 AM on February 22, 2014
So does this mean the bug only affects Mavericks on laptops/Macs? Thanks.
posted by miomiomio at 12:47 PM on February 22 [+] [!]
I think that's just confusing wording.... If you clicked through Safari, and it said not vulnerable, you're good to go.
posted by valkane at 9:52 AM on February 22, 2014
posted by miomiomio at 12:47 PM on February 22 [+] [!]
I think that's just confusing wording.... If you clicked through Safari, and it said not vulnerable, you're good to go.
posted by valkane at 9:52 AM on February 22, 2014
You're screwed if your Mac is on Mavericks; Apple has published the exploit but not the fix. Avoiding Safari will help a lot, but many MacOS applications rely on the broken library.
So... Is this serious enough to make a case for shifting from Mavericks to another computing environment for Internet stuff until a fix is issued, even if you're not using Safari?
posted by running order squabble fest at 9:55 AM on February 22, 2014 [1 favorite]
So... Is this serious enough to make a case for shifting from Mavericks to another computing environment for Internet stuff until a fix is issued, even if you're not using Safari?
posted by running order squabble fest at 9:55 AM on February 22, 2014 [1 favorite]
Pretty irresponsible for Apple to drop this on a Friday and not fix the vulnerable code in OSX at the same time.
Pretty par for the course for Apple's tech support. At least the important customers got a fix.
posted by davros42 at 9:55 AM on February 22, 2014 [1 favorite]
Pretty par for the course for Apple's tech support. At least the important customers got a fix.
posted by davros42 at 9:55 AM on February 22, 2014 [1 favorite]
Is this serious enough to make a case for shifting from Mavericks to another computing environment
Depends on how paranoid you are. I'm running Mavericks and choosing not to worry. So far I've heard of no active exploits; the bug has only been publically known for some 12 hours, it takes a little while to add a vulnerability to malware. And exploiting it still requires carrying off a MITM attack, at least in the simple scenarios.
If I had anything mission critical on my Mavericks box I'd feel differently. But for me, using Chrome instead of Safari is enough.
posted by Nelson at 9:59 AM on February 22, 2014 [1 favorite]
Depends on how paranoid you are. I'm running Mavericks and choosing not to worry. So far I've heard of no active exploits; the bug has only been publically known for some 12 hours, it takes a little while to add a vulnerability to malware. And exploiting it still requires carrying off a MITM attack, at least in the simple scenarios.
If I had anything mission critical on my Mavericks box I'd feel differently. But for me, using Chrome instead of Safari is enough.
posted by Nelson at 9:59 AM on February 22, 2014 [1 favorite]
Grrr. Grrrrrrrrr. I'm totally with Valkanes wife here- the ui is 'orrible.
posted by susiswimmer at 10:03 AM on February 22, 2014 [4 favorites]
posted by susiswimmer at 10:03 AM on February 22, 2014 [4 favorites]
Interesting - my iPhone 4 is still on iOs 5.0.1 and the test page says I'm not vulnerable. That's nice - was not keen to be forced into using iOs 7.
But the little guy's iPad mini is on iOs 7. Guess I'll upgrade it this weekend.
posted by dotgirl at 10:10 AM on February 22, 2014
But the little guy's iPad mini is on iOs 7. Guess I'll upgrade it this weekend.
posted by dotgirl at 10:10 AM on February 22, 2014
So I read that as iOS 6 is vulnerable as well. HOWEVER, when I updated my wife's iPad running 6, it jumped straight to 7 (through iTunes), with no option for the 6.1.6.
I've got 6.1.3 installed, and it shows my next option as 7.0.4, so I guess I'm taking the leap. Wish me luck!
posted by maudlin at 10:11 AM on February 22, 2014
I've got 6.1.3 installed, and it shows my next option as 7.0.4, so I guess I'm taking the leap. Wish me luck!
posted by maudlin at 10:11 AM on February 22, 2014
I'm running ios 6 on my iPhone four and I just checked my os upgrade in Settings and it is now downloading ios 7 and I didn't even ask for it. What the hell?????
posted by njohnson23 at 10:16 AM on February 22, 2014
posted by njohnson23 at 10:16 AM on February 22, 2014
This may be better for ask, but since we're all here anyways, and I suspect others may have the same issue...
I am trying to do the update on my iPad mini, which is currently on 6.1.3 and the test page shows is vulnerable.
When I try to load the update, it tells me the update fails because I am not connected to the internet. This is manifestly not the case. Suggestions?
posted by susiswimmer at 10:17 AM on February 22, 2014
I am trying to do the update on my iPad mini, which is currently on 6.1.3 and the test page shows is vulnerable.
When I try to load the update, it tells me the update fails because I am not connected to the internet. This is manifestly not the case. Suggestions?
posted by susiswimmer at 10:17 AM on February 22, 2014
Suggestions?
Plug it into iTunes and do the update from there.
posted by valkane at 10:21 AM on February 22, 2014 [1 favorite]
Plug it into iTunes and do the update from there.
posted by valkane at 10:21 AM on February 22, 2014 [1 favorite]
I've got 6.1.3 installed, and it shows my next option as 7.0.4, so I guess I'm taking the leap. Wish me luck!
You and me both, except I'm going straight to 7.0.6 through iTunes. We can be Ruined iPhone 4 buddies!
posted by pemberkins at 10:27 AM on February 22, 2014
You and me both, except I'm going straight to 7.0.6 through iTunes. We can be Ruined iPhone 4 buddies!
posted by pemberkins at 10:27 AM on February 22, 2014
Thanks valkane! Why it's going to take 20 minutes idk, but at least it's going.
posted by susiswimmer at 10:27 AM on February 22, 2014
posted by susiswimmer at 10:27 AM on February 22, 2014
Re: iOS 6.1.6
My reading of this page suggests that 6.1.6 is only for the iPhone 3GS and iPod touch, not iPhone 4 and later.
See also the system requirements here: http://support.apple.com/kb/DL1722
posted by mosk at 10:28 AM on February 22, 2014 [1 favorite]
My reading of this page suggests that 6.1.6 is only for the iPhone 3GS and iPod touch, not iPhone 4 and later.
See also the system requirements here: http://support.apple.com/kb/DL1722
posted by mosk at 10:28 AM on February 22, 2014 [1 favorite]
Thanks valkane! Why it's going to take 20 minutes idk, but at least it's going.
You're welcome! It takes a while because the jump from 6 to 7 is pretty big. BTW, my wife is convinced this is a conspiracy by Apple to force her to accept the new UI!
posted by valkane at 10:31 AM on February 22, 2014 [2 favorites]
You're welcome! It takes a while because the jump from 6 to 7 is pretty big. BTW, my wife is convinced this is a conspiracy by Apple to force her to accept the new UI!
posted by valkane at 10:31 AM on February 22, 2014 [2 favorites]
iOS 7 is not bad. I've been using it since its release on an iPad Retina and an iPhone 5.
Most of it is fine, I'm sure you're right. But I live and die by the calendar app. For this ui, it was like someone at apple said 'let's make it look like a blackberry calendar, but with less functionality!' Because that would be a good idea.
I'll get used to it, but there will be a venting and adjustment period. I suppose I just did the former, and should now get on with the latter...
posted by susiswimmer at 10:31 AM on February 22, 2014 [1 favorite]
Most of it is fine, I'm sure you're right. But I live and die by the calendar app. For this ui, it was like someone at apple said 'let's make it look like a blackberry calendar, but with less functionality!' Because that would be a good idea.
I'll get used to it, but there will be a venting and adjustment period. I suppose I just did the former, and should now get on with the latter...
posted by susiswimmer at 10:31 AM on February 22, 2014 [1 favorite]
BTW, my wife is convinced this is a conspiracy by Apple to force her to accept the new UI!
That's because they are. You're not paranoid if someone is actually out to get you!
posted by susiswimmer at 10:33 AM on February 22, 2014 [4 favorites]
That's because they are. You're not paranoid if someone is actually out to get you!
posted by susiswimmer at 10:33 AM on February 22, 2014 [4 favorites]
And thus the Internet is taught, once again, why goto's are evil, and not compiling with max warning levels set and paid attention to is bad coding practice.
Nothing to do with gotos. It's easy to write an equivalent bug with an extra "break" in a switch statement, or an extra "return" in any function. Really it's a dumb copy and paste bug that should have been caught in code-review or unit tests.
Or, as you mention, by turning on the right warning flags and also using -Werror to stop people from ignoring warnings.
posted by w0mbat at 10:34 AM on February 22, 2014 [3 favorites]
Nothing to do with gotos. It's easy to write an equivalent bug with an extra "break" in a switch statement, or an extra "return" in any function. Really it's a dumb copy and paste bug that should have been caught in code-review or unit tests.
Or, as you mention, by turning on the right warning flags and also using -Werror to stop people from ignoring warnings.
posted by w0mbat at 10:34 AM on February 22, 2014 [3 favorites]
Let me get this straight, my iPhone 4s and iPad4 are OK because I switched them to 7 a while ago, right? Both were hooked up to iTunes just recently (god I hate iTunes but that's another matter).
posted by Ber at 10:36 AM on February 22, 2014
posted by Ber at 10:36 AM on February 22, 2014
Good thing I'm running Windows XP SP1, I'm totally safe.
posted by entropicamericana at 10:38 AM on February 22, 2014 [11 favorites]
posted by entropicamericana at 10:38 AM on February 22, 2014 [11 favorites]
Nope! Your iOS7 installs MUST be patched ASAP!
(Oh -- it's ALIVE! IT'S ALIIIIVE!)
posted by maudlin at 10:39 AM on February 22, 2014
(Oh -- it's ALIVE! IT'S ALIIIIVE!)
posted by maudlin at 10:39 AM on February 22, 2014
It's --- slow. Slooooow. God, could they not at least Pezify the phone and dispense Concerta as needed?
posted by maudlin at 10:42 AM on February 22, 2014 [1 favorite]
posted by maudlin at 10:42 AM on February 22, 2014 [1 favorite]
Let me get this straight, my iPhone 4s and iPad4 are OK because I switched them to 7 a while ago, right?
Wrong. You wanna get updated to 7.0.6.
posted by valkane at 10:44 AM on February 22, 2014
Wrong. You wanna get updated to 7.0.6.
posted by valkane at 10:44 AM on February 22, 2014
Hopefully they'll fix this faster than the six weeks it took them to fix Java
Yes, because Apple is responsible for code from Oracle and Sun. :/
Anyway, use brackets in your conditional code, kids. Or turn on all the compiler warnings, including the extra stuff.
posted by Blazecock Pileon at 10:51 AM on February 22, 2014 [1 favorite]
Yes, because Apple is responsible for code from Oracle and Sun. :/
Anyway, use brackets in your conditional code, kids. Or turn on all the compiler warnings, including the extra stuff.
posted by Blazecock Pileon at 10:51 AM on February 22, 2014 [1 favorite]
Because some people in the thread are talking about this getting "added to malware", let's be explicit about the risk: someone malicious who is able to intercept or redirect your network traffic could fool your apple device into thinking they were a 'trusted' service. At this point your device could be tricked into downloading an app or OS update from an untrusted source, or your encrypted network traffic (like, your banking app or webpage, or email) could be decrypted.
You apple device isn't vulnerable simply sitting online, this isn't going to be a worm like in days of old. I would avoid doing anything sensitive over untrusted wifi, and I would not accept an app or OS update over untrusted wifi.
What's untrusted wifi? Anything in public, anything you don't control the router.
posted by These Premises Are Alarmed at 10:53 AM on February 22, 2014 [2 favorites]
You apple device isn't vulnerable simply sitting online, this isn't going to be a worm like in days of old. I would avoid doing anything sensitive over untrusted wifi, and I would not accept an app or OS update over untrusted wifi.
What's untrusted wifi? Anything in public, anything you don't control the router.
posted by These Premises Are Alarmed at 10:53 AM on February 22, 2014 [2 favorites]
So on Mavericks it's just, use Chrome and cross your fingers indefinitely?!
Man, Apple was already on my shitlist because I really am not pleased with my new Air. Now I dunno. Might ditch them entirely, I need a new phone anyway. AND I was thinking of buying a Windows laptop already.
posted by like_a_friend at 10:54 AM on February 22, 2014
Man, Apple was already on my shitlist because I really am not pleased with my new Air. Now I dunno. Might ditch them entirely, I need a new phone anyway. AND I was thinking of buying a Windows laptop already.
posted by like_a_friend at 10:54 AM on February 22, 2014
Yeah, on Mac OS, use Chrome and download the update when it's made available over your home network (if you have such a thing). If you don't have 'highly motivated' adversaries, and use a private internet connection, you should be fine.
Speaking of, Chrome is really the way to go for secure web browsing, on Mac OS or Windows. Not that they haven't had issues, but the security model and background updating in Chrome, as well as their leading-edge support for features like cert pinning, make it the best choice.
posted by These Premises Are Alarmed at 10:59 AM on February 22, 2014
Speaking of, Chrome is really the way to go for secure web browsing, on Mac OS or Windows. Not that they haven't had issues, but the security model and background updating in Chrome, as well as their leading-edge support for features like cert pinning, make it the best choice.
posted by These Premises Are Alarmed at 10:59 AM on February 22, 2014
So everyone is clear, the breakdown on i-devices is like this...
If your i-device is approved to run iOS 7, the 7-specific update is the one you will be offered, even if you are still running iOS 6. You will not be given the choice of the 6-specific update.
If your i-device is not cleared to run iOS 7, you will be given the 6-specific update.
So, for instance, if you're using an iPhone 4s, but still on iOS 6, you will have to upgrade to iOS 7 in order to get this patch.
As for Mac OSX, on my 10.6.8 iMac, Safari will not load the test page. Looks like the issue may be Mavericks-specific.
posted by Thorzdad at 11:02 AM on February 22, 2014 [1 favorite]
If your i-device is approved to run iOS 7, the 7-specific update is the one you will be offered, even if you are still running iOS 6. You will not be given the choice of the 6-specific update.
If your i-device is not cleared to run iOS 7, you will be given the 6-specific update.
So, for instance, if you're using an iPhone 4s, but still on iOS 6, you will have to upgrade to iOS 7 in order to get this patch.
As for Mac OSX, on my 10.6.8 iMac, Safari will not load the test page. Looks like the issue may be Mavericks-specific.
posted by Thorzdad at 11:02 AM on February 22, 2014 [1 favorite]
It's not just malicious baristas in your local coffee shop who can implement a MITM attack to exploit this bug. Consider that BGP hijacking is on the rise, so malicious parties could plausibly try to hijack google or bank of america or someone else's notable netblock for a little while and run a MITM attack there via a proxy server.
posted by rmd1023 at 11:06 AM on February 22, 2014 [2 favorites]
posted by rmd1023 at 11:06 AM on February 22, 2014 [2 favorites]
Nothing to do with gotos. It's easy to write an equivalent bug with an extra "break" in a switch statement, or an extra "return" in any function.
In some languages (Java's one of them) code placed after an unconditional break/throw/return will simply not compile. It's a bit embarrassing LLVM and GCC don't even give a warning for this code.
posted by grahamparks at 11:06 AM on February 22, 2014 [1 favorite]
In some languages (Java's one of them) code placed after an unconditional break/throw/return will simply not compile. It's a bit embarrassing LLVM and GCC don't even give a warning for this code.
posted by grahamparks at 11:06 AM on February 22, 2014 [1 favorite]
Sigh. I hate Chrome with the fire of a thousand suns, and do 90% of my work offsite on unsecured networks. Guess Mac can suck it, I'm buying a PC. Just wish this would have happened two weeks ago, before I wasted a shitload of money on an Air that isn't any good anyway.
posted by like_a_friend at 11:16 AM on February 22, 2014
posted by like_a_friend at 11:16 AM on February 22, 2014
The set of people who could perform a BGP hijacking attack but who don't also have a CA's private key is practically empty.
These Premises Are Alarmed nailed the risk for most users. I suppose it would be good to toss in the caveats for journalists in China/Iran, other people in oppressive regimes, etc.
I find it unlikely this would be added to malware, aside from public wifi-based infection vectors. Assuming the malware is already running on your system there are far easier ways for it to get at traffic.
Blazecock: As for Apple updating Java, as mentioned upthread, the issue was Oracle updated Java, and Apple didn't update their fork and push it via System Updates in a timely manner. Not that Apple is responsible for vulns in the jvm.
like_a_friend: Just use Firefox, it's based of NSS and thus isn't vulnerable.
posted by yeahwhatever at 11:20 AM on February 22, 2014 [3 favorites]
These Premises Are Alarmed nailed the risk for most users. I suppose it would be good to toss in the caveats for journalists in China/Iran, other people in oppressive regimes, etc.
I find it unlikely this would be added to malware, aside from public wifi-based infection vectors. Assuming the malware is already running on your system there are far easier ways for it to get at traffic.
Blazecock: As for Apple updating Java, as mentioned upthread, the issue was Oracle updated Java, and Apple didn't update their fork and push it via System Updates in a timely manner. Not that Apple is responsible for vulns in the jvm.
like_a_friend: Just use Firefox, it's based of NSS and thus isn't vulnerable.
posted by yeahwhatever at 11:20 AM on February 22, 2014 [3 favorites]
Yes, if you have Highly Motivated attackers now (you're a CEO, engineer at Google/Apple/FB/a bank, or journalist), this adds to your already considerable risk.
posted by These Premises Are Alarmed at 11:23 AM on February 22, 2014
posted by These Premises Are Alarmed at 11:23 AM on February 22, 2014
I like the term "clownshoes" to describe these sort of comically awful bugs. I think it's a Mozilla-ism.
posted by Rhomboid at 11:29 AM on February 22, 2014 [4 favorites]
posted by Rhomboid at 11:29 AM on February 22, 2014 [4 favorites]
So, if iOS/OS X can't validate the ssl cert, how does it know it is downloading the update from Apple's servers?
Yeah I made the same joke on Facebook. ;-) The update binary itself has to be signed by Apple, so there is a least one line of defense left.
posted by w0mbat at 11:39 AM on February 22, 2014
Yeah I made the same joke on Facebook. ;-) The update binary itself has to be signed by Apple, so there is a least one line of defense left.
posted by w0mbat at 11:39 AM on February 22, 2014
I think it's a mistake to dismiss this bug as only exploitable by a few sophisticated threats. SSL certificate verification is the lynchpin of trust in the network. This code is used in all sorts of places by applications to say "is this data coming from where it's supposed to? Can I trust it?". A lot of programmers are relying on that guarantee of trust, and once it's given goodness knows what else the code does. (For instance, Apple uses this code themselves to verify software updates, although people are saying they have a secondary code signing system too. I sure hope so, and that it doesn't also rely on this broken code.)
DNS hijacking, BGP hijacks, malicious wifi routers, there's a lot of ways MitM attacks happen in the real world from attackers of various skill levels. And I'm not sure that every single use of this broken code even requires a MitM attack to exploit; SSL certificates are used in non-network contexts too. The only reason I'm not freaking out is that no one's exploiting this widely yet and I don't feel like I'm likely to be a directed target.
Yes, because Apple is responsible for code from Oracle and Sun. :/
No, the Java exploit was in Apple's own Java distribution, and it took them six weeks to distribute the fixes that Oracle had given them. And only after a half million Macs got infected by a botnet. Browser exploits require faster action than that. So does this SSL flaw.
To be fair to Apple, they have gotten better since that mistake. They more or less disabled Java entirely (a good choice) and they've been faster about distributing patches since that incident two years ago. But they've done Mavericks users a terrible disservice in publicizing this SSL exploit without giving them a fix.
I wonder if they know something about an imminent threat to iOS users? Maybe they were worried about preventing an iOS jailbreak? Maybe they didn't realize that publishing an iOS patch would tip off the Mavericks bug? Or most horrifying, maybe Apple didn't realize they had the same bug in Mavericks.
posted by Nelson at 11:42 AM on February 22, 2014 [5 favorites]
DNS hijacking, BGP hijacks, malicious wifi routers, there's a lot of ways MitM attacks happen in the real world from attackers of various skill levels. And I'm not sure that every single use of this broken code even requires a MitM attack to exploit; SSL certificates are used in non-network contexts too. The only reason I'm not freaking out is that no one's exploiting this widely yet and I don't feel like I'm likely to be a directed target.
Yes, because Apple is responsible for code from Oracle and Sun. :/
No, the Java exploit was in Apple's own Java distribution, and it took them six weeks to distribute the fixes that Oracle had given them. And only after a half million Macs got infected by a botnet. Browser exploits require faster action than that. So does this SSL flaw.
To be fair to Apple, they have gotten better since that mistake. They more or less disabled Java entirely (a good choice) and they've been faster about distributing patches since that incident two years ago. But they've done Mavericks users a terrible disservice in publicizing this SSL exploit without giving them a fix.
I wonder if they know something about an imminent threat to iOS users? Maybe they were worried about preventing an iOS jailbreak? Maybe they didn't realize that publishing an iOS patch would tip off the Mavericks bug? Or most horrifying, maybe Apple didn't realize they had the same bug in Mavericks.
posted by Nelson at 11:42 AM on February 22, 2014 [5 favorites]
So if -Wall doesn't really mean "all", then what does? -Wkitchensink?
posted by benito.strauss at 11:49 AM on February 22, 2014 [3 favorites]
posted by benito.strauss at 11:49 AM on February 22, 2014 [3 favorites]
Maybe they were worried about preventing an iOS jailbreak?
That's not it, since iOS 7.0.5 was already jailbroken, and everything since the 3GS has required updates to be signed anyway, so this wouldn't enable jailbreaking anyway. There's lots of bad MITM attacks that this exposes you to but pushing out bogus updates is not one of them.
posted by aubilenon at 11:50 AM on February 22, 2014 [1 favorite]
That's not it, since iOS 7.0.5 was already jailbroken, and everything since the 3GS has required updates to be signed anyway, so this wouldn't enable jailbreaking anyway. There's lots of bad MITM attacks that this exposes you to but pushing out bogus updates is not one of them.
posted by aubilenon at 11:50 AM on February 22, 2014 [1 favorite]
There are a lot of compiler warnings that are more subjective than not, or which can trigger false positives on legitimate code, or which trigger on things that are outside of the user's control, and so on. If -Wall really enabled absolutely everything, it would be quite unpopular and nobody would use it. It's meant to be a blend of the most common, generally agreed upon warnings. Its name was probably a bad choice, but one which was made a long time ago. I personally use something like -Wall -Wextra -pedantic -std=c99 -O2 (or -std=c++11, or now -std=c++1y, or whatever.)
posted by Rhomboid at 11:59 AM on February 22, 2014 [2 favorites]
posted by Rhomboid at 11:59 AM on February 22, 2014 [2 favorites]
So if -Wall doesn't really mean "all", then what does? -Wkitchensink?
There's a ton of warnings that are less cut-and-dried. They are not included in -Wall, because some of them, frankly, are bullshit. And I'm not even convinced that unreachable code SHOULD be treated as an error. If you ever sanity-check an invariant, the fail case should be unreachable. Or if you have switch cases that only apply to some platforms but not others.
Plus if you do -Wall -Werror, every time they think of a new warning, your build may break. So if -Wall actually included everything, it would be less useful. It's too bad that the name is misleading, though.
-Wextra gives you some additional warnings that aren't included in -Wall. If you want to know what is available and not covered by -Wall, consult the documentation for your specific compiler.
posted by aubilenon at 12:05 PM on February 22, 2014 [1 favorite]
There's a ton of warnings that are less cut-and-dried. They are not included in -Wall, because some of them, frankly, are bullshit. And I'm not even convinced that unreachable code SHOULD be treated as an error. If you ever sanity-check an invariant, the fail case should be unreachable. Or if you have switch cases that only apply to some platforms but not others.
Plus if you do -Wall -Werror, every time they think of a new warning, your build may break. So if -Wall actually included everything, it would be less useful. It's too bad that the name is misleading, though.
-Wextra gives you some additional warnings that aren't included in -Wall. If you want to know what is available and not covered by -Wall, consult the documentation for your specific compiler.
posted by aubilenon at 12:05 PM on February 22, 2014 [1 favorite]
I have an iPod Touch running 6.1.5 and just checked. They're updating that, too, presumably for the same fix.
posted by Mental Wimp at 12:50 PM on February 22, 2014
posted by Mental Wimp at 12:50 PM on February 22, 2014
One thing that's especially awesome about this is that, as near as I can tell, you can't actually get OS X Server for 10.8 anymore.
I've heard they're only releasing security patches for 10.9 now, too. So, if you go back to 10.8 to avoid this, you'll just be trading one vulnerability for others.
posted by reprise the theme song and roll the credits at 1:05 PM on February 22, 2014
I've heard they're only releasing security patches for 10.9 now, too. So, if you go back to 10.8 to avoid this, you'll just be trading one vulnerability for others.
posted by reprise the theme song and roll the credits at 1:05 PM on February 22, 2014
Good time to mention Uncrustify, which, among many other nice things, can insert braces around any unbraced conditional bodies.
posted by tonycpsu at 1:07 PM on February 22, 2014 [2 favorites]
posted by tonycpsu at 1:07 PM on February 22, 2014 [2 favorites]
This is annoying, we didn't want to update my wife's iPhone 4 to iOS 7 for performance reasons, but so far it doesn't look like they are providing a iOS 6 fix that supports it.
posted by beowulf573 at 1:08 PM on February 22, 2014
posted by beowulf573 at 1:08 PM on February 22, 2014
Turn off iCloud, maybe turn off some of the animations. It's slow, but not killer rage slow.
posted by maudlin at 1:32 PM on February 22, 2014 [1 favorite]
posted by maudlin at 1:32 PM on February 22, 2014 [1 favorite]
I'm getting a little disillusioned about our glorious mobile future. When desktop computers were dominant, OSes were supported for years and years. Now it seems like you get one year of support for your mobile device until you don't even get critical security fixes anymore. If you don't want to upgrade to the more demanding OS that will slow down your device, tough, why don't buy a new phone?
posted by zixyer at 1:46 PM on February 22, 2014 [2 favorites]
posted by zixyer at 1:46 PM on February 22, 2014 [2 favorites]
I'm getting a little disillusioned about our glorious mobile future. When desktop computers were dominant, OSes were supported for years and years. Now it seems like you get one year of support for your mobile device until you don't even get critical security fixes anymore. If you don't want to upgrade to the more demanding OS that will slow down your device, tough, why don't buy a new phone?
Hey, at least it's not Android. There's a major vulnerability in the default Android browser that just came out in the past two days for any version of Android below 4.2. The vast majority of Android devices can't even be upgraded to 4.2! Don't have an upgradable phone? You're SOL. Apple gives you the option, even if it may impact performance.
posted by The Michael The at 2:01 PM on February 22, 2014 [3 favorites]
Hey, at least it's not Android. There's a major vulnerability in the default Android browser that just came out in the past two days for any version of Android below 4.2. The vast majority of Android devices can't even be upgraded to 4.2! Don't have an upgradable phone? You're SOL. Apple gives you the option, even if it may impact performance.
posted by The Michael The at 2:01 PM on February 22, 2014 [3 favorites]
Ha ha ha ha, I am still running 10.5.8, I do not fear your silly updates.
posted by maryr at 2:01 PM on February 22, 2014 [1 favorite]
posted by maryr at 2:01 PM on February 22, 2014 [1 favorite]
(On the other hand, I cannot run an up-to-date browser because no one supports Leopard anymore. Well, I'm sure that's not a security risk...)
posted by maryr at 2:03 PM on February 22, 2014
posted by maryr at 2:03 PM on February 22, 2014
Man, I upgraded via iTunes earlier - the update was a 1.9 GB download!
posted by Celsius1414 at 2:03 PM on February 22, 2014
posted by Celsius1414 at 2:03 PM on February 22, 2014
Now it seems like you get one year of support for your mobile device until you don't even get critical security fixes anymore.
They also released OS 6.1.6 with the same fix. It supports phones back to the iPhone 3GS, which is 4⅔ years old.
posted by aubilenon at 2:05 PM on February 22, 2014 [2 favorites]
They also released OS 6.1.6 with the same fix. It supports phones back to the iPhone 3GS, which is 4⅔ years old.
posted by aubilenon at 2:05 PM on February 22, 2014 [2 favorites]
For comparison, no Mac made in 1984 could run System 6, which was released in 1988. Though the notion of security updates was also pretty laughable for a system that had no security.
posted by aubilenon at 2:11 PM on February 22, 2014 [1 favorite]
posted by aubilenon at 2:11 PM on February 22, 2014 [1 favorite]
The Server.app that is currently available is for 10.9. If you want the Server.app that works on 10.8, and you don't already have it, then the only thing you can do is go on wanting, it seems.
posted by reprise the theme song and roll the credits at 2:19 PM on February 22, 2014
posted by reprise the theme song and roll the credits at 2:19 PM on February 22, 2014
In some languages (Java's one of them) code placed after an unconditional break/throw/return will simply not compile.
Yeah that would account for Java's excellent security record. Crap I broke my sarcasm meter again.
posted by w0mbat at 3:13 PM on February 22, 2014 [1 favorite]
Yeah that would account for Java's excellent security record. Crap I broke my sarcasm meter again.
posted by w0mbat at 3:13 PM on February 22, 2014 [1 favorite]
Code written is Java has a reasonably good security record. All the exploits and constant patching are for the JVM itself which is written in C. Doh.
posted by markr at 3:28 PM on February 22, 2014 [3 favorites]
posted by markr at 3:28 PM on February 22, 2014 [3 favorites]
Daring Fireball: On the Timing of iOS’s SSL Vulnerability and Apple’s ‘Addition’ to the NSA’s PRISM Program
posted by We had a deal, Kyle at 3:40 PM on February 22, 2014 [11 favorites]
posted by We had a deal, Kyle at 3:40 PM on February 22, 2014 [11 favorites]
Is there a site with a good summary of the problem and what to do about it, that covers both iOS and OSX, to send to non-technical people?
posted by moonmilk at 4:09 PM on February 22, 2014
posted by moonmilk at 4:09 PM on February 22, 2014
This is a great example of why competition in the browser space is important. On iOS, you don't have a choice of rendering engines (the core part of the browser) so this means that all of the browsers on iOS were vulnerable since October 2012 because they all have to use the same technology that Apple provides. This reason is why Mozilla cannot provide Firefox for the iPhone, because we use our own rendering engine, which apple doesn't allow.
Google does allow Mozilla to ship their own browser on Android which is why we do have Firefox on Android.
If you were using a different browser (not Safari) on your Mac, you would have been safe since Oct 2012.
(Disclaimer: I work for Mozilla but not on Firefox directly.)
posted by gen at 4:18 PM on February 22, 2014 [4 favorites]
Google does allow Mozilla to ship their own browser on Android which is why we do have Firefox on Android.
If you were using a different browser (not Safari) on your Mac, you would have been safe since Oct 2012.
(Disclaimer: I work for Mozilla but not on Firefox directly.)
posted by gen at 4:18 PM on February 22, 2014 [4 favorites]
>Is there a site with a good summary of the problem and what to do about it, that covers both iOS and OSX, to send to non-technical people?
Just ask them to update their devices ASAP.
posted by gen at 4:22 PM on February 22, 2014
Just ask them to update their devices ASAP.
posted by gen at 4:22 PM on February 22, 2014
>I wonder if they [Apple] know something about an imminent threat to iOS users?
The Snowden revelations displayed the NSA's accessibility to iOS in June of 2013. If Apple's security team wasn't actively researching this as soon as those revelations were made public...
If this fix was found as a result of the Snowden revelations, I am concerned by how many months it took Apple's security team to find and fix the vulnerability.
posted by gen at 4:37 PM on February 22, 2014 [1 favorite]
The Snowden revelations displayed the NSA's accessibility to iOS in June of 2013. If Apple's security team wasn't actively researching this as soon as those revelations were made public...
If this fix was found as a result of the Snowden revelations, I am concerned by how many months it took Apple's security team to find and fix the vulnerability.
posted by gen at 4:37 PM on February 22, 2014 [1 favorite]
On iOS, you don't have a choice of rendering engines (the core part of the browser) so this means that all of the browsers on iOS were vulnerable...
While I don't disagree with you regarding the lack of browser choice on iOS, I'd like to quibble with this statement a bit. This bug was in the iOS SSL implementation, not Apple's WebKit rendering engine. Apps have always been free to include their own implementation of SSL, should they care to do so. Google provides Chrome for iOS, and it uses Apple's WebKit, but it appears they used their own SSL implementation, so Chrome was not vulnerable.
posted by RichardP at 4:49 PM on February 22, 2014 [7 favorites]
While I don't disagree with you regarding the lack of browser choice on iOS, I'd like to quibble with this statement a bit. This bug was in the iOS SSL implementation, not Apple's WebKit rendering engine. Apps have always been free to include their own implementation of SSL, should they care to do so. Google provides Chrome for iOS, and it uses Apple's WebKit, but it appears they used their own SSL implementation, so Chrome was not vulnerable.
posted by RichardP at 4:49 PM on February 22, 2014 [7 favorites]
the six weeks it took them to fix Java
I know a way to fix Java in under two minutes.
posted by Twang at 5:07 PM on February 22, 2014 [4 favorites]
I know a way to fix Java in under two minutes.
posted by Twang at 5:07 PM on February 22, 2014 [4 favorites]
"find / -name java -delete"?
posted by eriko at 5:14 PM on February 22, 2014 [3 favorites]
posted by eriko at 5:14 PM on February 22, 2014 [3 favorites]
As a school netadmin having to deal with Apple's idiot rules for access to the iTunes app store, it's been my opinion for a while now that Apple's commitment to security theatre is second to none.
CONFIRMED WONTFIX
posted by flabdablet at 5:48 PM on February 22, 2014 [1 favorite]
CONFIRMED WONTFIX
posted by flabdablet at 5:48 PM on February 22, 2014 [1 favorite]
Apple sees you as absolute rubes.
posted by save alive nothing that breatheth at 5:52 PM on February 22, 2014 [1 favorite]
posted by save alive nothing that breatheth at 5:52 PM on February 22, 2014 [1 favorite]
The vast majority of Android devices can't even be upgraded to 4.2! Don't have an upgradable phone? You're SOL. Apple gives you the option, even if it may impact performance.
But on the other hand older iOS devices, including the not-very-old iPad 1, cannot be upgraded beyond iOS 5.1.1. It's a mere accident that the bug wasn't in those versions, and in that case many Apple users would be just as SOL as older Android device users. And there may well be such a bug found eventually, considering how the silly error that caused this one got through.
posted by JHarris at 5:54 PM on February 22, 2014 [2 favorites]
But on the other hand older iOS devices, including the not-very-old iPad 1, cannot be upgraded beyond iOS 5.1.1. It's a mere accident that the bug wasn't in those versions, and in that case many Apple users would be just as SOL as older Android device users. And there may well be such a bug found eventually, considering how the silly error that caused this one got through.
posted by JHarris at 5:54 PM on February 22, 2014 [2 favorites]
In related news, Guido van Rossum issued a statement saying "I TOLD YOU SO!"
posted by destrius at 6:36 PM on February 22, 2014 [4 favorites]
posted by destrius at 6:36 PM on February 22, 2014 [4 favorites]
I'm not sure what exactly you're refering to w/r/t Guido van Rossum, but a quick search on python vulnerabilities reveals... an SSL problem that allows man in the middle attacks!
posted by sbutler at 7:01 PM on February 22, 2014 [1 favorite]
posted by sbutler at 7:01 PM on February 22, 2014 [1 favorite]
I'm not sure what exactly you're refering to w/r/t Guido van Rossum, but a quick search on python vulnerabilities reveals... an SSL problem that allows man in the middle attacks!
Well, one reason the bug wasn't spotted as easily was that the indentation was off, which in Python would have resulted in the second goto being scoped within the if statement. But really I was just being snarky.
posted by destrius at 7:08 PM on February 22, 2014 [5 favorites]
Well, one reason the bug wasn't spotted as easily was that the indentation was off, which in Python would have resulted in the second goto being scoped within the if statement. But really I was just being snarky.
posted by destrius at 7:08 PM on February 22, 2014 [5 favorites]
Man, I upgraded via iTunes earlier - the update was a 1.9 GB download!
posted by Celsius1414 at 6:03 AM on February 23 [+] [!]
Over-the-air updates on the device itself only download the new bits. iTunes downloads the whole OS each time because of how it's set up to avoid jail breaking (or "security exploits," as it's more accurately known).
posted by DoctorFedora at 7:51 PM on February 22, 2014 [1 favorite]
posted by Celsius1414 at 6:03 AM on February 23 [+] [!]
Over-the-air updates on the device itself only download the new bits. iTunes downloads the whole OS each time because of how it's set up to avoid jail breaking (or "security exploits," as it's more accurately known).
posted by DoctorFedora at 7:51 PM on February 22, 2014 [1 favorite]
Well "exploit" in that the one doing the exploiting is the owner of the device. But it's helpful to know iTunes downloads the whole thing every time. That's not essential to preventing jailbreaks, but I guess it makes it easier?
posted by Nelson at 7:53 PM on February 22, 2014
posted by Nelson at 7:53 PM on February 22, 2014
Daring Fireball: On the Timing of iOS’s SSL Vulnerability and Apple’s ‘Addition’ to the NSA’s PRISM Program
Oh dear.
posted by homunculus at 10:02 PM on February 22, 2014 [1 favorite]
Oh dear.
posted by homunculus at 10:02 PM on February 22, 2014 [1 favorite]
I've been using iOS 7 on an iphone4s and ipad2 for months and still hate it.
Forcing older devices that can technically run an updated but slower OS to move to iOS 7 will be bad for apple's PR.
*shrug*
The usability of iOS 6 was what stopped me switching to an Android device. I find Android and iOS 7 equally tedious to use now, so I'll be banking the saved dollars next upgrade.
posted by bystander at 10:27 PM on February 22, 2014 [4 favorites]
Forcing older devices that can technically run an updated but slower OS to move to iOS 7 will be bad for apple's PR.
*shrug*
The usability of iOS 6 was what stopped me switching to an Android device. I find Android and iOS 7 equally tedious to use now, so I'll be banking the saved dollars next upgrade.
posted by bystander at 10:27 PM on February 22, 2014 [4 favorites]
Well "exploit" in that the one doing the exploiting is the owner of the device.
Except for tetherless jailbreaks, which are basically rootkits the device owner might or might not know about, sure.
posted by Blazecock Pileon at 11:01 PM on February 22, 2014
Except for tetherless jailbreaks, which are basically rootkits the device owner might or might not know about, sure.
posted by Blazecock Pileon at 11:01 PM on February 22, 2014
The set of people who could perform a BGP hijacking attack but who don't also have a CA's private key is practically empty.
But not empty enough - eg. 2 years ago when a pissant 3rd tier ISP took much of .au off the air with an accidental BGP leak.
posted by russm at 12:08 AM on February 23, 2014
But not empty enough - eg. 2 years ago when a pissant 3rd tier ISP took much of .au off the air with an accidental BGP leak.
posted by russm at 12:08 AM on February 23, 2014
Also, wrt BGP hijacking, having a CA's private keys generally won't help you if the client does cert pinning. CNNIC can easily issue a cert for the Apple software update server but the client won't trust it if the key fingerprint in the cert isn't what the client expects. Except, of course, that the client will trust it because double goto fail.
posted by russm at 12:36 AM on February 23, 2014
posted by russm at 12:36 AM on February 23, 2014
Well, in this case CA private keys and false certificates are a non-issue. The bug affects the ephemeral key signed by the server certificate. It fails to verify that the signature is correct, so the man in the middle can replace the ephemeral key with his own and the end point will be none the wiser.
But the man in the middle doesn't need to do anything with the certificates. Which is why this bug is so insidious.
From the article:
Now, if the link between the ephemeral key and the certificate chain is broken, then everything falls apart. It's possible to send a correct certificate chain to the client, but sign the handshake with the wrong private key, or not sign it at all! There's no proof that the server possesses the private key matching the public key in its certificate.
posted by sbutler at 12:49 AM on February 23, 2014
But the man in the middle doesn't need to do anything with the certificates. Which is why this bug is so insidious.
From the article:
Now, if the link between the ephemeral key and the certificate chain is broken, then everything falls apart. It's possible to send a correct certificate chain to the client, but sign the handshake with the wrong private key, or not sign it at all! There's no proof that the server possesses the private key matching the public key in its certificate.
posted by sbutler at 12:49 AM on February 23, 2014
I really don't know what to think about this. I mean, yes, it's a simple and understandable code mistake, but it's just such a perfect communications security hole. The whole thing kind of seems straight out of the Underhanded C Contest playbook.
posted by reprise the theme song and roll the credits at 12:58 AM on February 23, 2014 [5 favorites]
posted by reprise the theme song and roll the credits at 12:58 AM on February 23, 2014 [5 favorites]
I mean, yes, it's a simple and understandable code mistake
It might be simple, but I don't know about the "understandable" part. As Nelson pointed out upthread, it represents a really staggering failure of caution on Apple's part. There's any number of industry best practices that would have prevented this, but apparently they weren't following any of them.
I think it's better to assume incompetence than malice -- this would make a poor backdoor for the NSA or whoever, because it's less of a backdoor and more of a wide-open gate. They could have done something much more subtle if they'd wanted to. But it shows an alarming degree of carelessness.
posted by my favorite orange at 3:42 AM on February 23, 2014 [2 favorites]
It might be simple, but I don't know about the "understandable" part. As Nelson pointed out upthread, it represents a really staggering failure of caution on Apple's part. There's any number of industry best practices that would have prevented this, but apparently they weren't following any of them.
I think it's better to assume incompetence than malice -- this would make a poor backdoor for the NSA or whoever, because it's less of a backdoor and more of a wide-open gate. They could have done something much more subtle if they'd wanted to. But it shows an alarming degree of carelessness.
posted by my favorite orange at 3:42 AM on February 23, 2014 [2 favorites]
@susiswimmer: But I live and die by the calendar app.
ObJamesVanDerBeek: "I don't want your life!"
posted by HillbillyInBC at 4:54 AM on February 23, 2014 [1 favorite]
ObJamesVanDerBeek: "I don't want your life!"
posted by HillbillyInBC at 4:54 AM on February 23, 2014 [1 favorite]
Sigh. I hate Chrome with the fire of a thousand suns, and do 90% of my work offsite on unsecured networks. Guess Mac can suck it, I'm buying a PC. Just wish this would have happened two weeks ago, before I wasted a shitload of money on an Air that isn't any good anyway.
I'm not sure vendors are the source of the problems you're having.
posted by yerfatma at 6:55 AM on February 23, 2014 [7 favorites]
I'm not sure vendors are the source of the problems you're having.
posted by yerfatma at 6:55 AM on February 23, 2014 [7 favorites]
It would have made a great backdoor for someone for several months while it went undetected. Someone who doesn't worry much about collateral damage, or maybe someone whose home country doesn't use a lot of iPhones.
I'm not going to assume anything until Tim Cook drags the responsible engineer onstage during the next keynote, shows everyone the git blame output on the projector, and yells "You're all getting a free case, and it's coming out of this dummy's bonus"
posted by RobotVoodooPower at 8:51 AM on February 23, 2014 [2 favorites]
I'm not going to assume anything until Tim Cook drags the responsible engineer onstage during the next keynote, shows everyone the git blame output on the projector, and yells "You're all getting a free case, and it's coming out of this dummy's bonus"
posted by RobotVoodooPower at 8:51 AM on February 23, 2014 [2 favorites]
Is there a site with a good summary of the problem and what to do about it, that covers both iOS and OSX, to send to non-technical people?
posted by moonmilk
This at Tom's Guide is the best one-page resource that I've come up with so far.
posted by mississippi at 12:11 PM on February 23, 2014 [1 favorite]
posted by moonmilk
This at Tom's Guide is the best one-page resource that I've come up with so far.
posted by mississippi at 12:11 PM on February 23, 2014 [1 favorite]
It would have made a great backdoor for someone for several months while it went undetected.
several months? this has been in iOS since 6.0 according to Jeffrey Grossman.
posted by russm at 2:31 PM on February 23, 2014
several months? this has been in iOS since 6.0 according to Jeffrey Grossman.
posted by russm at 2:31 PM on February 23, 2014
t's not just malicious baristas in your local coffee shop who can implement a MITM attack to exploit this bug. Consider that BGP hijacking is on the rise, so malicious parties could plausibly try to hijack google or bank of america or someone else's notable netblock for a little while and run a MITM attack there via a proxy server.
Honestly, i think this is the real threat here.
A real, honest to goodness fake AP type MITM attack is something that only happens to people who are already being specifically targeted, or in hacker movies and stuff like this.
That's honestly something i think is neckbeardy, and missing from a lot of netsec discussions i've seen. Is a vulnerability really that bad if you need to say, have physical access to the hardware or set up a fake AP for your target to connect to?
DNS poisoning/hijacking or what you're describing is what makes this a gaping goatse hole, not a lot of the other exploit ideas i've seen fielded. This is of course, just like my opinion, maaan. But still.
posted by emptythought at 5:02 PM on February 23, 2014
Honestly, i think this is the real threat here.
A real, honest to goodness fake AP type MITM attack is something that only happens to people who are already being specifically targeted, or in hacker movies and stuff like this.
That's honestly something i think is neckbeardy, and missing from a lot of netsec discussions i've seen. Is a vulnerability really that bad if you need to say, have physical access to the hardware or set up a fake AP for your target to connect to?
DNS poisoning/hijacking or what you're describing is what makes this a gaping goatse hole, not a lot of the other exploit ideas i've seen fielded. This is of course, just like my opinion, maaan. But still.
posted by emptythought at 5:02 PM on February 23, 2014
Steven Bellovin has just posted about this in a post titled "Goto Fail". Of interest his claim that the bug is only triggered if "perfect forward secrecy" is offered as an encryption option for a session, and the possible ramifications of this.
posted by RichardP at 6:04 PM on February 23, 2014 [1 favorite]
posted by RichardP at 6:04 PM on February 23, 2014 [1 favorite]
It's an old-fashioned style, but a lot of Apple straight C code uses macros to wrap this style of error handling, which saves typing boiler plate code (and mis-typing it).
For example:
#define FailOnErr(a) do {err = (a) ; if (err) goto fail;} while(0)
FailOnErr(ReadyHash(&SSLHashSHA1, &hashCtx));
FailOnErr(SSLHashSHA1.update(&hashCtx, &clientRandom));
FailOnErr(SSLHashSHA1.update(&hashCtx, &serverRandom));
FailOnErr(SSLHashSHA1.update(&hashCtx, &signedParams));
FailOnErr(SSLHashSHA1.final(&hashCtx, &hashOut));
These days I avoid macros and goto and would write it differently, but not as compactly.
posted by w0mbat at 2:19 PM on February 24, 2014 [1 favorite]
For example:
#define FailOnErr(a) do {err = (a) ; if (err) goto fail;} while(0)
FailOnErr(ReadyHash(&SSLHashSHA1, &hashCtx));
FailOnErr(SSLHashSHA1.update(&hashCtx, &clientRandom));
FailOnErr(SSLHashSHA1.update(&hashCtx, &serverRandom));
FailOnErr(SSLHashSHA1.update(&hashCtx, &signedParams));
FailOnErr(SSLHashSHA1.final(&hashCtx, &hashOut));
These days I avoid macros and goto and would write it differently, but not as compactly.
posted by w0mbat at 2:19 PM on February 24, 2014 [1 favorite]
From juiceCake's link: Based on the findings, potential attackers can either use phishing to mislead the victim to install a malicious/vulnerable app or exploit another remote vulnerability of some app, and then conduct background monitoring.
Excuse what may be a naive question, but does this mean this exploit depends either on the user downloading a malicious app (which could just directly key-log) or download an app with a different security hole (which could be exploited directly)? If the answer is yes, then why does this represent any additional security threat?
posted by Mental Wimp at 9:53 AM on February 25, 2014
Excuse what may be a naive question, but does this mean this exploit depends either on the user downloading a malicious app (which could just directly key-log) or download an app with a different security hole (which could be exploited directly)? If the answer is yes, then why does this represent any additional security threat?
posted by Mental Wimp at 9:53 AM on February 25, 2014
No, it's a deeper problem. The bug means SSL certificate verification does not work. That verification is how software knows that it's talking to who its thinking its talking to. So when I go to type my password in to, say, Apple.com the way I know it's really Apple.com is SSL. Because of this bug, a man-in-the-middle attacker could impersonate Apple and I wouldn't know.
Inevitable single-serving site: hasgotofailbeenfixedyet.com. ("No". Also contains links to useful info.)
posted by Nelson at 10:12 AM on February 25, 2014
Inevitable single-serving site: hasgotofailbeenfixedyet.com. ("No". Also contains links to useful info.)
posted by Nelson at 10:12 AM on February 25, 2014
Nelson: " Inevitable single-serving site: hasgotofailbeenfixedyet.com. ("No". Also contains links to useful info.)"
Actually, yes. (Installing fix now.)
posted by tonycpsu at 10:16 AM on February 25, 2014 [1 favorite]
Actually, yes. (Installing fix now.)
posted by tonycpsu at 10:16 AM on February 25, 2014 [1 favorite]
Hmm, yes, Apple has released Mavericks v10.9.2. Nothing in the official release notes about the SSL fix, but it's being reported that it includes one. Presumably details will show up on the security notes page soon.
10.9.2 also includes an SMB2 fix, for which I am most grateful. They broke filesharing pretty badly in Mavericks.
posted by Nelson at 10:47 AM on February 25, 2014
10.9.2 also includes an SMB2 fix, for which I am most grateful. They broke filesharing pretty badly in Mavericks.
posted by Nelson at 10:47 AM on February 25, 2014
why does this represent any additional security threat?
It's a new threat because apps that run in the background aren't supposed to be able to access or log touch events of the app running in the foreground. Imagine you download a music player app which runs in the background and surreptitiously records and exfiltrates everything you do. Prior to this, a malicious app could not "just directly key-log", because that capability isn't supposed to exist, that's the vuln.
posted by Rhomboid at 12:58 PM on February 25, 2014 [2 favorites]
It's a new threat because apps that run in the background aren't supposed to be able to access or log touch events of the app running in the foreground. Imagine you download a music player app which runs in the background and surreptitiously records and exfiltrates everything you do. Prior to this, a malicious app could not "just directly key-log", because that capability isn't supposed to exist, that's the vuln.
posted by Rhomboid at 12:58 PM on February 25, 2014 [2 favorites]
Hmm, yes, Apple has released Mavericks v10.9.2. Nothing in the official release notes about the SSL fix, but it's being reported that it includes one.
Just updated. The gotofail.com page says "safe."
posted by chococat at 1:37 PM on February 25, 2014 [1 favorite]
Just updated. The gotofail.com page says "safe."
posted by chococat at 1:37 PM on February 25, 2014 [1 favorite]
About the security content of OS X Mavericks v10.9.2 and Security Update 2014-001: Apple's official security release notes. The upgrade worked for me too. There's a whole lot of changes here, it's not just a point release for the SSL bug.
There's a lot of reports that the iOS 7.0.6 update is bricking iPhones. I'd discount that but a friend of mine got hit with this problem. My own 5S was fine though.
posted by Nelson at 3:15 PM on February 25, 2014
There's a lot of reports that the iOS 7.0.6 update is bricking iPhones. I'd discount that but a friend of mine got hit with this problem. My own 5S was fine though.
posted by Nelson at 3:15 PM on February 25, 2014
My iPhone4 seems fine after the update.
They still haven't fixed a weird audio stutter that I get when I play audio through my interface using anything that uses the Quicktime 10 codecs (Any flash audio in Safari, Quicktime10, etc.).
Had it since the Mavericks update.
Chrome: fine
Quicktime7: fine
Using Safari for YouTube, Soundcloud, etc.: fine
So annoying.
posted by chococat at 4:19 PM on February 25, 2014
They still haven't fixed a weird audio stutter that I get when I play audio through my interface using anything that uses the Quicktime 10 codecs (Any flash audio in Safari, Quicktime10, etc.).
Had it since the Mavericks update.
Chrome: fine
Quicktime7: fine
Using Safari for YouTube, Soundcloud, etc.: fine
So annoying.
posted by chococat at 4:19 PM on February 25, 2014
QT10 shouldn't be playing Flash audio unless you're doing something very, very weird...
posted by schmod at 5:29 PM on February 25, 2014
posted by schmod at 5:29 PM on February 25, 2014
Oh yeah, I meant playing things in Safari. YouTube is fine, but Mefi Music, Bandcamp, embedded Soundcloud sounds in Twitter, etc. all stutter when played in Safari browser, but fine in Chrome.
From what I've gathered from other people with the same issue, it's some weird thing with Mavericks and Quicktime10. Fine in QT7.
Driving me nuts.
posted by chococat at 6:31 PM on February 25, 2014
From what I've gathered from other people with the same issue, it's some weird thing with Mavericks and Quicktime10. Fine in QT7.
Driving me nuts.
posted by chococat at 6:31 PM on February 25, 2014
Thanks, Rhomboid, your explanation makes sense.
posted by Mental Wimp at 1:07 PM on February 26, 2014
posted by Mental Wimp at 1:07 PM on February 26, 2014
For jailbroken devices, there is a Cydia package called SSLPatch that purports to fix this.
posted by exogenous at 8:29 PM on February 26, 2014 [1 favorite]
posted by exogenous at 8:29 PM on February 26, 2014 [1 favorite]
And it seems to have worked! Glad I don't have to deal with am iOS "upgrade"
posted by exogenous at 8:40 PM on February 26, 2014
posted by exogenous at 8:40 PM on February 26, 2014
A similar bug has been found in the GnuTLS package , which is used in many Linux distributions and in GPL licensed software, which is a big chunk of open source software. It is thought that this bug has been around for nearly a decade.
Since this affects servers and VPNs, I would consider this a far more devastating bug than the iOS and OS X, as those applications are more consumer oriented.
I'm beginning to understand a bit more why Bruce Schneier has been advocating layered security for so long. We can't really trust SSL/TLS, as the protocol itself is subject to new attacked continually, and we've been through so many versions to get to something that we think is perhaps now secure, and meanwhile the majority of websites use versions of SSL that are well know to be insecure.
SSL should really only be a single layer of security In a multilayer scheme. It can't be the sole protection of secrets because it's a near certainty that there are extant weaknesses in nearly all implementations, and probably in the protocols themselves. Perhaps it's time for a parallel implementation of these ideas, using separate methods and ciphers, to double layer everything, with security intact even if one of the layers fails? At least for very important things. SSL/TLS should be viewed with suspicion.
posted by Llama-Lime at 1:11 AM on March 5, 2014 [3 favorites]
Since this affects servers and VPNs, I would consider this a far more devastating bug than the iOS and OS X, as those applications are more consumer oriented.
I'm beginning to understand a bit more why Bruce Schneier has been advocating layered security for so long. We can't really trust SSL/TLS, as the protocol itself is subject to new attacked continually, and we've been through so many versions to get to something that we think is perhaps now secure, and meanwhile the majority of websites use versions of SSL that are well know to be insecure.
SSL should really only be a single layer of security In a multilayer scheme. It can't be the sole protection of secrets because it's a near certainty that there are extant weaknesses in nearly all implementations, and probably in the protocols themselves. Perhaps it's time for a parallel implementation of these ideas, using separate methods and ciphers, to double layer everything, with security intact even if one of the layers fails? At least for very important things. SSL/TLS should be viewed with suspicion.
posted by Llama-Lime at 1:11 AM on March 5, 2014 [3 favorites]
« Older Paul WS Anderson looks back on his directorial... | Prisoners and Their Dilemma Newer »
This thread has been archived and is closed to new comments
posted by sammyo at 8:15 AM on February 22, 2014 [7 favorites]