8 ms·

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 th

by ambrop7 13y ago

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 the private key it claims to posses. > it seems far less crucial than remote-code-execution > I don't understand why this is getting more attention that other (seemingly) more dangerous exploits. Because it's the foundation for a heap of applications and services that were believed to be secure due to use of SSL. If you consider those, this is worse than any bug in any application. It's not just one application with a critical vulnerability - effectively, it's half (or whatmany) of all OSX and iOS apps with a critical vulnerability. All you need to do is go browse the net in a coffee shop, and some stranger can easily do things like: - Pwn your box (MITM the auto update). Actually with this he can do all of the latter too. - Steal your money (MITM your bank connection). - Steam your online accounts, including email. It's not "just a bug". Yes, everyone makes mistakes, we're all human. 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. > That's certainly a problem, but most people are using trustworthy ISPs Your argument seems to be that it's not a big issue if the security is totally broke since we don't need security in the first place.

ctolsen 13y ago
It's even more unacceptable that it took them FOUR DAYS to fix it, just so they could add a couple of features to FaceTime while they were at it.
- joeblau 13y ago
  Facetime Audio on Mac! Heck yes, finally.
- mrmondo 13y ago
  While this is too long IMO, Similarly critical bugs in windows have been left unfixed for years.
  - ctolsen 13y ago
    While that may have been true, I dare say that the burnt child that is today's Microsoft would not have mishandled this so horribly.
- silencio 13y ago
  Have you seen the content of the security update? It doesn't really excuse the 4 days between iOS and OS X updates, but it's a hell of a lot more than FaceTime updates. http://support.apple.com/kb/HT6150 http://support.apple.com/kb/HT6150
- renaudg 13y ago
  10.9.2 has been in beta for weeks and was evidently just about to be released. It made a lot of sense from a QA perspective to do it just the way they did.
  - magicalist 13y ago
    I'm fully on board with the "bugs happen" point of view, but if they really have had this particular fix in the pipeline for weeks, then no, they really really should have done an out of band update of a much smaller scope.
chimeracoder 13y ago
> 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 release notes![0] If you look at the release notes for this update, you'd have no idea how important this is, if you didn't already know. [0] The release notes (http://support.apple.com/kb/HT6114 http://support.apple.com/kb/HT6114) link to this: http://support.apple.com/kb/HT1222 http://support.apple.com/kb/HT1222 , which as of right now, lists Dec. 16th as the most recent OS X security update.
- eridius 13y ago
  > 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.
  - codeka 13y ago
    >The only alternative would have been to delay the iOS release Right. This is basically Apple violating their own "responsible disclosure" policy and announcing a 0-day vulnerability in OS X. They should have delayed the release of the iOS patch until the OS X one was ready. This is the whole point of responsible disclosure: maybe the vulnerability is being used in the wild, but by delaying release of it until the vendor can patch it, the potential for expoitation is greatly reduced. >All this did was make more people aware of it, and only then for a few days. You say that as if it's not a big deal...
nsxwolf 13y ago
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?
- ambrop7 13y ago
  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 probably isn't someone impersonating it (note however that anyone with the PSK can impersonate the access point). Remember kids, when you connect to a network without a PSK or more elaborate authentication where you verify the identity of the AP, you generally have no idea who is operating that network.
  - nsxwolf 13y ago
    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?
    - danudey 13y ago
      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).
    - deleted 13y ago
      [deleted]
- danudey 13y ago
eslaught 13y ago
> "It's not "just a bug". Yes, everyone makes mistakes, we're all human. 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." This is not a reasonable argument. At Pwn2Own each year, how many browsers have vulnerabilities that allow remote code execution? All of them. How many of these vulnerabilities are zero-days? A significant number of those. This happens every single year. Even the advanced protections in e.g. Chrome don't stop new vulnerabilities from being found on a regular basis. And all of these products are deployed to millions of users. You could complain about Apple's response to this bug, and that might be a reasonable complaint to make. At least Google patches bugs quickly when they surface at Pwn2Own. But that's different from claiming the bugs shouldn't have existed (or should have been caught before making it into production). Bugs are fundamentally hard to find, and it's not really getting any easier.
- ambrop7 13y ago
  As I said: It's not just another security bug. It's an easy to spot bug, in the most critical part of the code, of a fundamental security library. THIS is what makes it unacceptable. It pretty much means the change has never gone through code review, or has been planted.
  - res0nat0r 13y ago
    While working at AWS and seeing outages being posted here, and the wildly inaccurate summaries (guesses) of what the problems were, and the wildly simplistic fixes that are assumed to easily be put in place I can say: systems like this are more complicated than you think they are.
    - renaudg 13y ago
      A huge +1 to this, from someone who worked at Facebook.
    - nicholassmith 13y ago
      Agreed, everyone enjoys playing armchair critic and in the majority of the time have no idea how the internal systems are structured or managed.
dubcanada 13y ago
I may be wrong but is part of WebKit and not just Safari? In which case this isn't solely apple.
- mehrdada 13y ago
  It's part of neither. The bug is in Secure Transport, the system SSL/TLS implementation in OS X and iOS, that Safari, Mail, and many third party apps (almost all apps that use SSL/TLS on iOS and OS X) rely on for TLS communications.
Zhenya 13y ago
What does it mean to "steam your online account"?

by ambrop7 13y ago

ctolsen 13y ago

It's even more unacceptable that it took them FOUR DAYS to fix it, just so they could add a couple of features to FaceTime while they were at it.

joeblau 13y ago
Facetime Audio on Mac! Heck yes, finally.
mrmondo 13y ago
While this is too long IMO, Similarly critical bugs in windows have been left unfixed for years.
- ctolsen 13y ago
  While that may have been true, I dare say that the burnt child that is today's Microsoft would not have mishandled this so horribly.
silencio 13y ago
Have you seen the content of the security update? It doesn't really excuse the 4 days between iOS and OS X updates, but it's a hell of a lot more than FaceTime updates. http://support.apple.com/kb/HT6150 http://support.apple.com/kb/HT6150
renaudg 13y ago
10.9.2 has been in beta for weeks and was evidently just about to be released. It made a lot of sense from a QA perspective to do it just the way they did.
- magicalist 13y ago
  I'm fully on board with the "bugs happen" point of view, but if they really have had this particular fix in the pipeline for weeks, then no, they really really should have done an out of band update of a much smaller scope.

chimeracoder 13y ago

> 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 release notes![0] If you look at the release notes for this update, you'd have no idea how important this is, if you didn't already know. [0] The release notes (http://support.apple.com/kb/HT6114 http://support.apple.com/kb/HT6114) link to this: http://support.apple.com/kb/HT1222 http://support.apple.com/kb/HT1222 , which as of right now, lists Dec. 16th as the most recent OS X security update.

eridius 13y ago
> 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.
- codeka 13y ago
  >The only alternative would have been to delay the iOS release Right. This is basically Apple violating their own "responsible disclosure" policy and announcing a 0-day vulnerability in OS X. They should have delayed the release of the iOS patch until the OS X one was ready. This is the whole point of responsible disclosure: maybe the vulnerability is being used in the wild, but by delaying release of it until the vendor can patch it, the potential for expoitation is greatly reduced. >All this did was make more people aware of it, and only then for a few days. You say that as if it's not a big deal...

nsxwolf 13y ago

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?

ambrop7 13y ago
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 probably isn't someone impersonating it (note however that anyone with the PSK can impersonate the access point). Remember kids, when you connect to a network without a PSK or more elaborate authentication where you verify the identity of the AP, you generally have no idea who is operating that network.
- nsxwolf 13y ago
  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?
  - danudey 13y ago
    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).
  - deleted 13y ago
    [deleted]
danudey 13y ago

eslaught 13y ago

> "It's not "just a bug". Yes, everyone makes mistakes, we're all human. 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." This is not a reasonable argument. At Pwn2Own each year, how many browsers have vulnerabilities that allow remote code execution? All of them. How many of these vulnerabilities are zero-days? A significant number of those. This happens every single year. Even the advanced protections in e.g. Chrome don't stop new vulnerabilities from being found on a regular basis. And all of these products are deployed to millions of users. You could complain about Apple's response to this bug, and that might be a reasonable complaint to make. At least Google patches bugs quickly when they surface at Pwn2Own. But that's different from claiming the bugs shouldn't have existed (or should have been caught before making it into production). Bugs are fundamentally hard to find, and it's not really getting any easier.

ambrop7 13y ago
As I said: It's not just another security bug. It's an easy to spot bug, in the most critical part of the code, of a fundamental security library. THIS is what makes it unacceptable. It pretty much means the change has never gone through code review, or has been planted.
- res0nat0r 13y ago
  While working at AWS and seeing outages being posted here, and the wildly inaccurate summaries (guesses) of what the problems were, and the wildly simplistic fixes that are assumed to easily be put in place I can say: systems like this are more complicated than you think they are.
  - renaudg 13y ago
    A huge +1 to this, from someone who worked at Facebook.
  - nicholassmith 13y ago
    Agreed, everyone enjoys playing armchair critic and in the majority of the time have no idea how the internal systems are structured or managed.

dubcanada 13y ago

I may be wrong but is part of WebKit and not just Safari? In which case this isn't solely apple.

mehrdada 13y ago
It's part of neither. The bug is in Secure Transport, the system SSL/TLS implementation in OS X and iOS, that Safari, Mail, and many third party apps (almost all apps that use SSL/TLS on iOS and OS X) rely on for TLS communications.

Zhenya 13y ago

What does it mean to "steam your online account"?