Live data from Hacker News

Apple releases OS X Mavericks 10.9.2 with SSL fix

9to5mac.com

141–150 of 246 posts

Re: Apple releases OS X Mavericks 10.9.2 with SSL fix

#141
post #80

Earlier quoted context omitted.

It's getting attention because: - It's an easy to spot bug, - in the most critical part of the code, - of a fundamental security library, - and it's been there for a long time, nobody knows how many systems have already been compromised due to it. With this bug, Apple's library isn't actually a SSL implementation. It does not perform the most essential part of a SSL implementation - verifying that the peer possesses…

> But it's completely unacceptable that those mistakes get unnoticed and into production code of such a critical component, and deployed to millions of users. The handling has been abysmal as well. They dropped a 0-day on themselves by releasing the iOS update, and then delayed the fix by several days, apparently so they could release it along with the Facetime integration. And even then they don't mention it on the…

> The handling has been abysmal as well. They dropped a 0-day on themselves by releasing the iOS update, and then delayed the fix by several days, apparently so they could release it along with the Facetime integration.

The only alternative would have been to delay the iOS release, which they didn't do because almost certainly this bug was already being exploited in the wild. All this did was make more people aware of it, and only then for a few days.

As for OS X release, I'm sure they released it as fast as they could. It has nothing to do with releasing along with FaceTime integration, and everything to do with 10.9.2. was already going through the GM process, and it was faster/easier to add this fix into that and continue trying to validate the GM than it was to spin up an entirely new train for a 10.9.1.1 with just this fix and try to validate that.

Re: Apple releases OS X Mavericks 10.9.2 with SSL fix

#142
post #90

Earlier quoted context omitted.

This is true with or without this bug.

Without this bug, they wouldn't be able to use BofA's own certificate to do it.

They can't use BofA's own certificate anyway, because the domain doesn't match.

Re: Apple releases OS X Mavericks 10.9.2 with SSL fix

#143
post #98
post #22

Ahh, so they probably had to restart the QA on the whole release a few days ago (including FaceTime Audio and associated features) after adding the TLS fix at the last minute. It makes a bit more sense why they'd make us wait a few days, now.

I think it's more likely that both were in the pipeline, and QA finished iOS 7.0.6 first - last week, and QA for 10.9.2 was slated to finish this week. So do you hold it or not? Is it more critical to have 4 days of protection, or 4 days of "WTF is Apple incompetent" press?

I know I'd choose 4 days of protection instead of 4 days of bad press :)

Re: Apple releases OS X Mavericks 10.9.2 with SSL fix

#144
post #80

Earlier quoted context omitted.

It's getting attention because: - It's an easy to spot bug, - in the most critical part of the code, - of a fundamental security library, - and it's been there for a long time, nobody knows how many systems have already been compromised due to it. With this bug, Apple's library isn't actually a SSL implementation. It does not perform the most essential part of a SSL implementation - verifying that the peer possesses…

How many malicious exploits have occurred in the last 5 days? I'm genuinely curious if anyone has a guess. Wouldn't you need to have control of the router Starbucks is using to set up the MITM attack?

Because iOS (and Mac OS) automatically connects to known WiFi hotspot names, it's possible to create a hotspot named the same as Starbucks's WiFi, even if you're nowhere near a Starbucks, and iOS will happily connect to it if possible (unless other preferred networks around and it picks them over you).

Also, a lot of smaller coffee shops will just set up a wifi router and give it a password and call it done, when many of them have inherent exploits.

On top of all that, there are lots of Asus routers out there running firmware that can be remotely exploited and for which there is no patch[1]. Or Linksys routers[2]. Or D-Link[3].

All an attacker needs to do is change your DNS server settings and they can send you to any server they want instead of the server that you expected. They could redirect all HTTP and HTTPS requests to common services through their servers, MITM your connections to Facebook, Twitter, Apple, Bank of America, your e-mail, your health insurance website, etc.

On its own it's safe, but if you have control of someone's WiFi router (which is apparently trivial) then it's entirely possible for someone to snoop on a huge swath of your supposedly secure internet traffic.

The only real saving grace here is that OS code signing hasn't been compromised, so the system won't install a backdoor'ed 10.9.2 update. At least that part of the chain is secure and people can update.

    [1] http://threatpost.com/unpatched-vulnerabilities-disclosed-in-asus-home-routers/101317
    [2] http://www.pcworld.com/article/2098520/exploit-released-for-vulnerability-targeted-by-linksys-router-worm.html
    [3] http://hexus.net/tech/news/network/61245-easy-exploit-backdoor-found-several-d-link-router-models/

Re: Apple releases OS X Mavericks 10.9.2 with SSL fix

#145

Earlier quoted context omitted.

Anyone can hide his access point in a backpack and claim to be Starbucks. Or anything else - most people don't care, they'll hook themselves to just about anything. This isn't true of home networks using PSK, where the AP and the client need an identical PSK in order to authenticate each other. Yes, each other - if you successfully connect to an AP using a PSK, you can be pretty sure that AP knows the same key, and p…

What stops someone from doing that anyway, with their own hot spot, and just serving a self-signed certificate? Will the browser remember the old certificate, and put up the warning?

A self-signed certificate will throw an error in the browser because the certificate chain isn't trusted (even if you have the appropriate key).

In SSL, you have the certificate and the key; the key is private and secret, and the certificate is public. A public certificate which is wrong (e.g. self-signed) does you no good because browsers won't trust it (and many of them have made it frustrating to try to bypass the warning).

Re: Apple releases OS X Mavericks 10.9.2 with SSL fix

#146

Earlier quoted context omitted.

Anyone can hide his access point in a backpack and claim to be Starbucks. Or anything else - most people don't care, they'll hook themselves to just about anything. This isn't true of home networks using PSK, where the AP and the client need an identical PSK in order to authenticate each other. Yes, each other - if you successfully connect to an AP using a PSK, you can be pretty sure that AP knows the same key, and p…

What stops someone from doing that anyway, with their own hot spot, and just serving a self-signed certificate? Will the browser remember the old certificate, and put up the warning?

[deleted]

Re: Apple releases OS X Mavericks 10.9.2 with SSL fix

#147
post #106
post #83

Earlier quoted context omitted.

Coffe Shops, Airports, your insecure home wlan, your office, GSM networks... actually, do you use tls at all or you just go plain text because you're using a "trustworthy ISP"?

This seems like the key to me. Seems naive to think that your trusted ISP is the only person you'll ever get internet access through.

Seems naive to think that your ISP can be trusted, since they can be compelled by law and sworn to secrecy.

Re: Apple releases OS X Mavericks 10.9.2 with SSL fix

#148

Earlier quoted context omitted.

Unless your box has already been pwnd and the update installer has been modified to not install that update in the way it was meant to be.

Yes, if we assume you're already fucked, then we can conclude that there is nothing you can do to verify anything and that you are fucked, because we have assumed our conclusion. SHA1s and MD5s are equally pointless in this case because you've already assumed you're fucked, so it should all be assumed to be lying to you. If, however, we don't engage in circular reasoning and we assume your box isn't currently in the…

If, however, we don't engage in circular reasoning

I agree with the point you're making, but you can also turn this idea around, after which it serves to highlight how insanely inadequate our current tools and infrastructure are from a security standpoint.

Basically, you can only reasonably hope to verify a patch if you're not already owned, so you also have to assume you're not in order to verify. It's as if there was a contagious disease that has a good chance of killing you after a number of years, but the diagnostic tests can only be counted on to work if you don't have the disease in the first place. So then why would anyone ever bother getting tested? Our current situation is that uncomfortable.

Re: Apple releases OS X Mavericks 10.9.2 with SSL fix

#149

Earlier quoted context omitted.

How many malicious exploits have occurred in the last 5 days? I'm genuinely curious if anyone has a guess. Wouldn't you need to have control of the router Starbucks is using to set up the MITM attack?

Because iOS (and Mac OS) automatically connects to known WiFi hotspot names , it's possible to create a hotspot named the same as Starbucks's WiFi, even if you're nowhere near a Starbucks, and iOS will happily connect to it if possible (unless other preferred networks around and it picks them over you). Also, a lot of smaller coffee shops will just set up a wifi router and give it a password and call it done, when ma…

If you configure that hotspot name with WPA-PSK, it should not attempt to connect to hotspots with the same name that are not WPA-PSK. If the hotspot it tries to connect to does not have a matching PSK, it should fail the handshake (and no, the client isn't disclosing the PSK to anyone during the handshake). If any of this is not true, that would be another vulnerability.

Also WPA-PSK is useless for coffee shops because you have to give the PSK to everyone, and with that the ability to impersonate the AP. For that purpose, EAP/TLS is better, assuming you take care to verify the AP's certificate.

Re: Apple releases OS X Mavericks 10.9.2 with SSL fix

#150
What I wonder, is if Apple can be held responsible (to some extent) for damages that resulted due to this bug for app developers like a bank whose customers were robbed because the bank relied on the secure connection as it should have been provided by the Apple API. Clearly, the attacker is still the person to have exploited the bug but I think a developer should be able to assume that Apples security relevant API functionalities are indeed secure.
Post reply on HN