151–160 of 246 posts
I haven't upgraded to Mavericks at all yet because I'm worried that it will break software I depend on a daily basis. Can some please confirm if upgrading has a significant risk of breaking compatibility with things like rails, mamp, netbeans, android studio, golang, vagrant, virtualbox, docker etc.
Thanks
Earlier quoted context omitted.
> 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 o…
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...
Earlier quoted context omitted.
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 w…
Being owned is less like having a virus and more like having schizophrenia. You can't ever expect to self-verify yourself, because if you're suffering from it, everything you're perceiving is being filtered through a compromised and untrustworthy system.
You have to trust some third-party that you believe to not be similarly compromised to do the verification for you.
Forgive me, but I'm not really sure why this is getting so much attention. It's certainly a bad bug, and it ought to have been caught. But it feels like this would be much harder to exploit than many other bugs which have had far less hoopla. As I understand, this SSL bug makes it rather trivial to perform MITM attacks against apps which use the default system SSL libs. That's certainly a problem, but most people are…
Compare the reporting of this to the Chrome vulnerability in TLS patched yesterday... https://news.ycombinator.com/item?id=7295785
Forgive me, but I'm not really sure why this is getting so much attention. It's certainly a bad bug, and it ought to have been caught. But it feels like this would be much harder to exploit than many other bugs which have had far less hoopla. As I understand, this SSL bug makes it rather trivial to perform MITM attacks against apps which use the default system SSL libs. That's certainly a problem, but most people are…
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…
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.
Apple has also changed the behavior of the power button on notebooks. Previously, pressing the button made the Mac instantly go to sleep. Now, just pressing it doesn't do anything. You can still hold the power button for 3 seconds to get the usual "Are you sure you want to shut down your computer now?" dialog box. Awesome for those of us using FileVault who have to enter their login password each time they wake up th…
This changed back when 10.9 was released: http://support.apple.com/kb/HT5869
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…
> "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-day…
This bug was pretty serious. I'd better be extra careful and install and verify this myself. Oh, good: there's a standalone installer available ( http://support.apple.com/kb/DL1726 ). But the download is served over HTTP. Maybe I can just try the same URL with HTTPS: $ curl --head https://support.apple.com/downloads/DL1726/en_US/OSXUpdCombo10.9.2.dmg HTTP/1.1 302 Moved Temporarily Server: Apache/2.2.24 (Unix) Locatio…
In addition to pillf's suggestion: 1. Use linux/fbsd/obsd/win box to download update. 2. Verify authenticity of cert/sha1 3. scp dmg / copy to USB drive 4. Apply update and move on.
If you're 13, add "duh" at the end.
Forgive me, but I'm not really sure why this is getting so much attention. It's certainly a bad bug, and it ought to have been caught. But it feels like this would be much harder to exploit than many other bugs which have had far less hoopla. As I understand, this SSL bug makes it rather trivial to perform MITM attacks against apps which use the default system SSL libs. That's certainly a problem, but most people are…
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…