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:
Nope. Well, at least I can verify the SHA1 sum displayed on the download page. Wait, no, that was served over HTTP, too.
Okay, I'll follow Apple's instructions for checking the certificate fingerprint in the installer (http://support.apple.com/kb/ht5044).
But that page (Last modified November 2011) displays a different fingerprint (9C864771 vs FA02790F)...and that fingerprint was also served over HTTP.
The packages themselves are signed: Mount the .dmg file and use pkgutil --check-signature /path/to/Installer.pkg to check whether the package is signed by a valid CA (if you want to be totally sure, do this check on a machine running 10.8 or earlier)
FWIW, I did this for the combo update. The SHA1 checksum on the Apple page, c06a63982b522e43997a05cedc04b0bdb1a10207, matches the file, and pkgutil reports
Package "OSXUpdCombo10.9.2.pkg":
Status: signed Apple Software
Certificate Chain:
1. Software Update
SHA1 fingerprint: 1E 34 E3 91 C6 44 37 DD 24 BE 57 B1 66 7B 2F DA 09 76 E1 FD
-----------------------------------------------------------------------------
2. Apple Software Update Certification Authority
SHA1 fingerprint: FA 02 79 0F CE 9D 93 00 89 C8 C2 51 0B BC 50 B4 85 8E 6F BF
-----------------------------------------------------------------------------
3. Apple Root CA
SHA1 fingerprint: 61 1E 5B 66 2C 59 3A 08 FF 58 D1 4A E2 24 52 D1 98 DF 6C 60
This is all pointless handwaving; the update package itself is signed and will not install if tampered with, regardless of TLS certs used to download it.
Meh, just admit you didn't realise how packages are signed and move on. TLS shouldn't and cannot be used to sign installation packages. After all, TLS stands for _Transport Layer_ Security...
Well you have the right to feel offended, but he really didn't "follow logical steps and make a fair enough point" as his idea was completely wrong when it comes to signing installation packages.
Yes. That's the marketing page explaining how Gatekeeper works, but yes, in the end it's a feature of Gatekeeper that makes it harder for you to open unsigned packages and impossible to open packages with a broken signature.
So even when you don't know about pkgutil (most people don't), Gatekeeper will still help you.
"Mom, First use linux/fbsd/obsd/win box to download update. Next verify authenticity of cert/sha1. Then just scp dmg / copy to USB drive, apply update and move on."
That is a cute response. The only problem is that you are substituting "mom" for OP.
Did the mother of your thirteen year old preface her question with "I already tried to use curl but then I realized that would not work. Then I thought I could verify the SHA1 but I realized I was obtaining the sha1 value over an insecure channel."?
Steady now, that's my mother you're talking about...
I agree that context matters. That's why statistically the proposed solution isn't a solution. It doesn't really work in a way that address the serious issue because the serious issue is the sheer magnitude of the number of compromised systems.
To put it another way, if you have a Linux or Windows or BSD box why keep a potentially deeply compromised OSX installation around at all. The patch isn't going to unpwn a pwnd box. The hoops might insure the patch isn't compromised but in terms of system security the horse is out of the barn and all the way to the glue factory.
The only case where jumping through those hoops makes a difference is in the second best case. And that's statistically equivalent to the best case and preparing for the best case in regard to security goes by the name of "wishful thinking."
Seems ironic that of all the patches that don't get served over SSL, the "SSL is meaningless" bug is the one where you'd point out that SSL should be available :P
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 using trustworthy ISPs (at least in this sense). Comcast seems unlikely to try to steal your bank password, and Verizon is unlikely to try to harvest your HN cookies.
It seems like this primarily affects people connecting to untrustworthy access-points, such as Coffee Shops, or Airport Wifi - While that's certainly something that needs to be fixed, it seems far less crucial than remote-code-execution [1], or many other bugs we see regularly.
I'm sure I'm missing something here, can someone help me understand?
Is it just the "Ick" factor of having something you thought was encrypted actually being fairly open?
I don't understand why this is getting more attention that other (seemingly) more dangerous exploits.
- 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.
> 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.
> 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.
>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.
As I said, the iOS bug was almost certainly already being exploited. Delaying the release of a fix for that seems like the absolute last thing anyone should be suggesting they do.
There is no justification for this bug. It never should have shipped. It never should have gone unnoticed for so long. It never should have been announced prior to a patch being available.
No matter how you slice it, Apple failed miserably, and "iOS was probably being exploited" is not an excuse. Apple has how much money? How much money do you think it costs to put their entire Core OS engineering staff on SHIPPING AN UPDATE FOR BOTH OPERATING SYSTEMS?
They could have afforded it. They were simply too incompetent, after a chain of incompetence, to do so.
In arguing that they should add more people in order to ship faster, the only incompetence on display is your own. That's not how software development works, which you should know if you've done it professionally.
Huh? It's a one line change. The patch has to be validated across the entire testing matrix of their entire product line. That is a trivially parallelizable problem.
Don't cargo cult 'common wisdom'; the only incompetence on display here is your axiomation of things you don't understand.
If you'd meant QA, you would have said QA, not engineering. You don't want engineers doing QA, which you would also know if you actually worked in the industry. They're notoriously bad at it. You'd also know that a test cycle takes a certain amount of time, and for something as complex as OS X, that amount is going to be measured in days per configuration, and there's nothing you can do about that -- adding more people will, again, just slow it down. Admit you don't know what you're talking about and move on. Or just stop talking, whatever.
Please have the bridge delivered to my home between noon and six.
(Though, really, I should just accept this absurd statement, since it amounts to you admitting your own incompetence.)
> Stop trying to acquire internet points by being a jerk.
This from the guy who decided his scintillating contribution to the thread would be redundantly accusing people of "apologism" and "incompetence". You do understand the people who actually do work at Apple are human beings, and that you are flinging insults at them, right?
The point of responsible disclosure (as opposed to telling the company and then not telling anyone) is to force the company into action, and force them to fix it with the threat of public disclosure later
> 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.
If this is true, then their process could use some adjustment. Contrast with Google Chrome which has the regular motion of changes going through channels, but the ability to update virtually all clients within a matter of hours if a critical issue is found.
(I realize there is a lot more QA necessary for an OS update, but I'm not convinced that a fix for this specific bug would have taken a long time to QA. Certainly not anywhere near as long as we've waited for this update, or as long as a lot of people will delay installing it because it is huge.)
The hell with GM process. There should be a way to push out simple changes like this, as soon as possible, for cases like this which is very important.
Which is why you need a process for shipping out emergency fixes. Microsoft can do it in 24 hours, and on the desktop, the impact of a broken build for Microsoft is staggeringly large when compared to Apple.
The GM process is there precisely to stop bugs like this malingbit into production. Who knows how many potential bugs it has stopped. You can't know.
To play the devil a bit, their process still needs some work, there isn't a good reason why they couldnt have released this patch in its own approval process simultaneously with a higher priority for staff to choose it over facetime.
From https://gotofail.com/faq.html:
"I have been seeing Apple IP addresses hitting the site with fixed browsers identifying as OS X 10.9.2 since Saturday morning Cupertino time."
> "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.
While it's true that almost all software has bugs that can result in exploits, I think most of the exploits used in Pwn2Own are typically the result of complex interactions between subsystems that are hard to predict. As software gets more complex, the attack surface increases.
The Apple bug isn't really in that class of exploit. It's a simple coding/merge error, and it's actually a regression from previously working code. One of the things that worries me is that this bug would have been caught so easily with basic unit tests.
Test 1: Make connection to server with a valid SSL certificate [PASSED]
Test 2: Make connection to a server with an invalid SSL certificate [FAILED]
Are we meant to think that Apple's build process doesn't use unit testing? Seems unlikely. Or perhaps this component didn't warrant an extensive test suite? I hope not! Not really sure what the explanation is.
I mean, I certainly can't claim that all my code is run through extensive tests before every deploy, but then I'm not working on the security tools that underpin an entire operating system.
In this case, the very test you're describing would not have worked. For a better writeup, see agl's post[1] on the matter. The basic gist of it: On affected systems, the server may use any combination of private key and certificate. Most SSL libraries used on the server side will make sure the moduli of cert and private key match (and abort if this isn't the case). Unit testing would thus require a server with some modifications to its SSL library (OpenSSL, in most cases).
What would have caught the bug: automatic code indentation or any sort of compile-time warnings about dead code.
I see what you mean, the amount of work and foresight needed to predict the bug and write a test for it does seem unrealistic in that light. Hingdsight is 20/20, etc.
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.
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.
> “It pretty much means that the change has never gone through code review, or has been planted.” Or Hanlon's Razor; “Never attribute to malice that which is adequately explained by stupidity.” Going straight to dumb-ass conspiracy theories it what is unacceptable.
No. To err is human. In the grand scheme of things, it's a PR fuck up; nothing more. I doubt it affects you directly enough as a Gentoo user to have such a strong reaction anyway, but if it make you feel superior, then all power to you. Lighten up and have a look at this and ask your self if you have honestly never done the same thing: http://xkcd.com/292/ if you think you haven't, I can gaur tee that you are deluding yourself...
The error is not that of the programmer's. The fault is not in code, it's in processes that were chosen by management.
Indeed, to err is human. This is why you're a negligent jackass if you don't plan for errors and build multiple systems to prevent and detect them, at least until computers start programming themselves for us.
I dont even know what that would mean, to make an existing vulnerability 'unacceptable'.
Vulnerabilities of all kinds exist. We need to find them, learn from them and we need to fix them.
Getting hung up on whether or not they are 'acceptable' is just kind of weird.
Bad stuff happens, incompetence happens, mistakes happen. None of that is 'acceptable', but it happens just the same.
Creating an environment where some kinds of mistakes are 'unacceptable' doesn't eliminate those kinds of mistakes, it just causes people to stop reporting them.
Complaining about their release cycle makes some sense. complaining about the existence of an existing bug is basically just howling at the moon.
This is so different from Pwn2Own I don't even know where to start. This failure case shows up in the most basic test case of what the library is supposed to do. The whole point of having certificate validation is that you identify invalid certificates. Try to come up with a reason why there are no regression tests with the library and why there wasn't a regression test that verified that for the default case, an invalid certificate was reported as such.
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.
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.
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.
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.
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.
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.
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).
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.
- It really is a severe bug in a major platform (and by that I mean iOS not MacOS)
- It is easy to understand once spotted, so everybody who can read code in the entire planet can write about how stupid Apple is because they refuse to see the light and switch over to their favorite pet language/coding standard/methodology
- The NSA has massive MITM capabilities and is known to sabotage American products and this looks like a very, very convenient bug to have for them, leading to speculation that this could not be a mistake
"Forgive me, but I'm not really sure why this is getting so much attention."
Because because the level of professional incompetence it exhibits in a world where people think using iPods as part of an airline's essential safety process is a fucking whizzing of an idea. It makes the first order problem of using iPods to transmit confidential medical records feel rather trivial.
Yet there is nothing for which you need ask forgiveness. A model of the world where everyone lives in circumstances where either Comcast or Verizon is always available for one's internet connection [and it goes without saying that neither could possibly be compromised] is so absurd that you can only be speaking tongue in cheek
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"?
That's actually a quite easy to understand problem as well.
The difference is pretty major. It's believable that someone forgot to consider the case where a new certificate was negotiated. It's downright inconceivable that no one tested whether a bad certificate failed validation. That's like selling a pregnancy test without testing what happens if the person isn't pregnant.
> That's certainly a problem, but most people are using trustworthy ISPs (at least in this sense). Comcast seems unlikely to try to steal your bank password, and Verizon is unlikely to try to harvest your HN cookies.
But if you are tricked to go to bankofamericaa.com instead of bankofamerica.com, a crook can be the proxy between you and your bank and you are none the wiser.
The difference is this bug will grant you the lock icon, and your browser will "guarantee" you're speaking to the real bankofamerica.
Practically speaking, that probably doesn't matter, because someone who understands that won't click on an email and log in to bankofamericaa.com. But there is a difference.
It is very easy to get a lock icon on bankofamericaa.com and to get your browser to insist you are speaking to the real bankofamericaa. What makes this bug interesting is you can get a lock icon for a fake website on bankofamerica.com using a MITM attack: making convincing "secure" websites on alternative URLs has always been possible.
Why does this matter? The browser isn't even at bankofamerica.com, it is at bankofamericaa.com: it "adds insult to injury", but it doesn't affect the attack. No browser would notice, even with the fanciest watchdog services and certificate pinning, that the certificate of an unrelated website is "authentic" or not. The only way you are going to notice the name being wrong is if the user opens the certificate details dialog and reads the content; do you seriously think someone is going to do this and not look at the URL ;P? What this bug makes possible are not the age-old "wrong URL" attack, but an active MITM on the real URL.
Well yeah, but the point is there's nothing stopping the attackers from putting a valid certificate on bankofamericaa.com to make that green bar appear.
I believe that the recent NSA revelations are the primary reason this bug is so concerning. We already know that the US government has access to the majority of packets being routed across the US, and this bug makes it trivial to decrypt those originating from Apple devices.
> That's certainly a problem, but most people are using trustworthy ISPs (at least in this sense). Comcast seems unlikely to try to steal your bank password, and Verizon is unlikely to try to harvest your HN cookies.
You got it! Really when you think about it, why do we even bother with crypto on the Internet in the first place? It's not like your data is traveling over a series of networks and nodes with different owners/operators that you don't even know and certainly haven't vetted for trustworthiness. That'd be crazy.
Have you not seen the news, at all, for the past several months? There have been a few revalations that perhaps some ISPs are not entirely trustworthy, to say the least...
Apple hating seems to be the new trend and I see it as the main reason for thus much attention.
That, and also for the fact that if Steve Jobs were still around, he'd be able to sweep this up or else be able to assuage the public about the 1 extra line of goto fail;
I think that in the post-Jobs future, we'll see more and more "revelations" about bugs/issues within Apple/iOS/OS X with people aggressively posting as much info as possible to "stick it to Apple"
If you trust every network hop, are sure that you are never impacted by aberrant if not even malicious routes, never touched by DNS spoofing....SSL becomes irrelevant, doesn't it?
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.
They already knew about the TLS issue. Remember, they found and fixed it themselves. It is not like Apple's release of iOS 7.0.6 was what alerted Apple to the vulnerability in OS X.
The problem was not coordinating the release of 10.9.2 and iOS 7.0.6. The other problem is their patching cycle in general.
This update includes many high severity fixes from mid 2013 and one issue as far back as 2011. That tells you all you need to know about Apple's security program management. They release uncoordinated and when they feel like it, with no sense of urgency. It's convenient for them to just toss critical security fixes in to their 6 month OS updates, so they do.
Some criticize Microsoft for their "slow" patching, but they at least have a dedicated monthly cycle just for security updates, and they will send them out of band if a 0day gets exposed. And rarely will you see them drop 0day on themselves (though this wasn't always the case).
It makes a bit more sense why they'd make us wait a few days, now.
It's still terrible. They should have pushed out a fix for this vulnerability first and push back 10.9.2 if necessary. Or perhaps introduce a modern package system for the base system.
You still need a minimal amount of testing and release packing. 4 days for an OS update is pretty good response time IMHO, and I thank the Apple engineers that probably worked their asses off to get this mess sorted out.
What this doesn't excuse is disclosing the iOS bug before all fixes are ready. THAT was the major scrweup.
Nope, I disagree. Microsoft releases emergency hotfixes within about 24 hours usually, if a security vuln is critical enough. And this one is definitely extremely critical.
Let's be honest, Microsoft is better at security than Apple, mostly as auto-immune response, but regardless of the cause, they've been battle-tested and they know how to handle it.
Microsoft has had to deal with more security issues for obvious reasons. Apple has not had a serious security protocol on the basis of assuming the platform is flaw free. Even if that were the case, it's how seriously and professionally each is handled is what builds or breaks PR/credibility. IOW, you're only as good as your last performance.
Did you read the release notes? There were several arbitrary code exec overflows and a sandbox bypass that were patched as well. Nobody is freaking out that these took days or weeks to ship...
4 days for an OS update is pretty good response time IMHO
For quite a serious vulnerability, which requires removing one goto statement to solve? I am not sure by what standards that is a good response time. There is surely something wrong with Apple's procedures here.
Yes, if you don't test and it stops all the devices with X installed you will have a lot of unhappy customers. And no fix, however simple is risk free.
They could have done the OSX testing at the same time as the iOS and the AppleTV testing. Remember, it's not 4 days response time, it's (4 days + however long the ios response time was). They unleashed a 0day on themselves.
Apple had more than 4 days. Apple knew about and fixed the iOS bug. We don't know when they became aware of the SSL bug (in iOS & OSX), but it certainly wasn't on the day that Apple released the OSX bug
Its totally unacceptable. Even Microsoft does patches of this severity in less than 24 hours.
I suspect what this points to is that Apple doesn't have automated testing and they need a bunch of old school "hands on keyboards testers" to run a test case list that takes 4 days.
The parent 'suspects' and doesn't actually know. It's not 'totally unacceptable' either. It's over a weekend and it's a set of trade offs about cutting a release made by a bunch of smart engineers who were probably very tired (last week for them has probably sucked) and they've just pulled a long weekend to get this out the door.
If you find this 'totally unacceptable', my suggestion would be to either go join them and help them improve the situation or to move to another OS. Bitching on the internet merely indicates how little experience you have with the trade offs that need to be made when pushing latge volumes of software.
> my suggestion would be to either go join them and help them improve the situation
Uhh no, we're customers. I don't find it unacceptable but if I did, it's within my rights to say so without "help[ing] them" as I pay the Apple Tax happily and repeatedly.
"Even Microsoft" is terribly wrong. In fact Microsoft is several years in advance to other software companies regarding security lifecycle of its products.
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?
This should really have been a separate fix & installed without user interaction. Instead this is 450 Megs & requires a restart. It'll take days for it to get out to those at risk.
The fun thing to think about is whether or not you can guarantee that the update you receive is actually from Apple and not someone sending you a fake via MITM.
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 possession of the Russian mafia or (insert preferred APT here), then how can one be reasonably confident that the update one receives through the updater is legitimately the one Apple is distributing?
Because it is signed and the code-signing verification was not broken by this bug.
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.
> 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.
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.
If anyone from Apple is reading and can influence this - could you convince whomever needs to be convinced that you ought to have less vague/shitty release notes, particularly wrt issues like this?
They cover security issues in a separate announcement (listed on http://support.apple.com/kb/HT1222), but only a few hours after the update has been released. I do think high-impact security issues like this SSL bug deserve a mention in the release notes as well.
Looks like they're just trying to not make it obvious that Macs can have security problems. I don't think many regular users (who probably think Macs are invincible) are going to actively look for security announcements about their invincible Mac. And when they look at the release notes, many of them won't be convinced to stop what they're doing and install some unnecessary updates.
I wonder if their hope is everything transitions to something like iOS before this is falsified in a widespread way on OSX in public.
In corporate settings with desktop management, Macs are actually a huge pain to deal with; Windows maybe starts from crappier defaults but there's a much more mature industry around locking it down.
most definitely the right person is reading this, Apple is a bottom-up corporation and someone reading HN could just talk to their manager and have the complaint heard by the right person.
>Safari can't open the page "https://www.imperialviolet.org:1266" because Safari can't establish a secure connection to the server "www.imperialviolet.org".
That day was the last 4 days , between when Apple disclosed the SSL bug by patching it in iOS(effectively zero daying themselves) and when they bothered to fix it in OSX. If you are in North America, please contact the National Security Agency to retrieve your messages. For Asia, please contact the Chinese Ministry of State Security.
No, it's just a bug of the SecureTransport backend in curl [1]. I thought Apple maintains the backend as nobody else uses it (homebrew curl uses OpenSSL) and that's why I've submitted the issue to Apple instead to the curl maintainer.
So maybe it brought some eyes on the "gotofail" but that's just speculation…
So in order to show the importance of this security update, they've put it in bland writing in a long, detailed security notice that only the most ardent of admins would read thoroughly, and even then it doesn't particularly stand out as important.
Regular Jane and John Does or even power users would have no idea of the importance of upgrading their system for this. "500MB update? Nah, it can wait, I don't need any of that".
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 their computer.
The parent is correct. In 10.9, pressing the power button put the computer to sleep, replacing the dialog prompt shown in your link. As of 10.9.2, simply pressing it does nothing at all.
Interesting: After the update, ocspd downloaded roughly 40MB of ... certificate revocation lists?
ocspd
/usr/sbin/ocspd
Total: 196 B sent, 45.8 MB received
Outgoing to devimages.apple.com (92.122.207.101), Port http (80), Protocol TCP (6), 196 B sent, 45.8 MB received
I think that's not related to the SSL/TLS bug, but instead to the curl problem that also came with the update to 10.9.2. This is the description from Apple's security mailing list:
"curl
Available for: OS X Mavericks 10.9 and 10.9.1
Impact: An attacker with a privileged network position may intercept user credentials or other sensitive information
Description: When using curl to connect to an HTTPS URL containing an IP address, the IP address was not validated against the certificate. This issue does not affect systems prior to OS X Mavericks v10.9.
CVE-ID CVE-2014-1263 : Roland Moriz of Moriz GmbH"
Tested with OS X 10.8.5 and Safari 6.0.5, gotofail.com declared the bug wasn't present. (At first, it declined to run the test, having concluded it didn't need to; following the link to explicitly run the test gave the "safe" result)
FWIW, applying the security update also installs iTunes 11, which users of Requiem may want to take note of.
A compelling way to get holdouts to upgrade iOS/OSX. Get those iPhone 4 folks who are content with iOS 6.x to install iOS 7.x.
God only knows what incompetence and disregard for user privacy and sanity awaits in these "new" versions. What are they adding that we really need? Oh, the ability to use SSL PKI. Yeah, I guess you have to upgrade.
Why isn't HN discussing the effects this screw up has on email? Email is bigger than the web, belive it or not.
And most of the world appears to use webmail.
With this "bug" HTTPS for your webmail is futile.
You have no way to know you are connecting to the real googlemail, yahoomail, hotmail, etc.
The "authentication" functions of SSL need to be made an compilation option, not a default.
It's obvious almost no knows or cares how to use SSL's PKI mechanism properly.
SSL's encryption capabilities have been useful, but using SSL to do server authentication causes more problems than it solves.
History has shown it's just not easy enough to use.
SSH can do authentication without PKI. Alas, it is embedded into a program that only nerds use.
I'm using the authentication framework in CurveCP. I'm working on making it very easy to use.
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.
Remember that software license you clicked while installing ? Most likely it had something like:
THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
So yeah Apple can't be held responsible. If they could then the whole free software open source community would be in deep doo doo.
Does it have a precedent with gaziilions of other bugs on all platforms?
It is really fun to watch how "hey I understand this one" turns into "the most dangerous and evil bug on any platform evah".
PHP
Available for: OS X Lion v10.7.5, OS X Lion Server v10.7.5,
OS X Mountain Lion v10.8.5, OS X Mavericks 10.9 and 10.9.1
Impact: Multiple vulnerabilities in PHP
Description: Multiple vulnerabilities existed in PHP, the most
serious of which may have led to arbitrary code execution <…>
Didn't know it's in Mac OS X… But yeah, it is… /usr/bin/php
Both the webserver (Apache) and PHP are off by default and have to be enabled separately, the latter by editing a config file.
Essentially, only Mac-owning web developers who enable these things (and serve PHP from their box to the world) are affected by any security problems in PHP. I imagine that most such web developers actually only dev locally and push the code to another server. It's nice that they updated them anyway.
I've got a similar USB issue. I have a SATA HDD in an External USB 3.0 enclosure. When my 2011 iMac wakes from sleep, it needs to wait for the external drive to spin up. Major PITA.
Having similar weird USB issues on my 13" late 2013 MBP. It's been really, really crappy since I bought it. Same issues with keyboard and touchpad breaking under random applications. Apple seems to be completely ignoring the issue aside from a botched "fix" in November.
edit - oh wow I just read what this fix's. Will be updating asap
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.
I would hope the built-in software-upgrade process does exactly that (independent of transport-layer SSL), but I have no evidence either way.
The manual-download pages on http://support.apple.com/downloads/ publish SHA1 sums. Unfortunately those pages aren't served over SSL. You could download the update and compare its hash against those of your friends: at least then you'd all be installing the same thing (preventing narrowly-targetted attacks).
If it was an honest mistake, they're not going to publically throw an employee under the bus.
If it was a malicious action from the NSA, they're not allowed to make it public.
I suspect the only hypothetical way we'd hear about the "who" is if an employee weakened it for his own personal gain, and criminal charges were raised.
I have not read much in regards to WHY this exact same bug was also found in OSX. Can anyone shed some light on this?
Do they use the same code stack for iOS and OSX? This seems weird to me - even though parts of code could be used in both operating systems, I would imagine separate teams would be on iOS and OSX, each reviewing code bases on their own, running unit tests and whatnot. Still, this major flaw has been present for 2.5(?) years - all the more reason for paranoia about its presence.
Add to this, why wait so long with the OSX update? A security issue THIS serious MUST be patched instantly and rolled out as an individual/separate update as soon as possible, even if that means pushing back OSX 10.9.2. Or did they need some time to introduce a new flaw somewhere? o_O
I'm confused -- the osx dev center doesn't have 10.9.2 at all (any build), only the original October 10.9 release. I guess that happens whenever they push a new release?
to fix it I had to reset my Keychain. Pain in the ass, but it was preventing me from working.
To do this, open Keychain Access, open Preferences, and click Reset Keychain. It will create a new login keychain and keep your old one backed up in the keychains folder.
OS X Mavericks audio problems are still not fixed. Audio dropouts in Google Chrome more often than once per second when a lot of tabs are open. Makes for example Youtube unbearable to watch. Chrome audio worked fine in OSX 10.8 with a lot more tabs.
Are you sure it's not a chrome bug? Obviously chrome updated itself many times in the meantime. Do you see this same bug even in different contexts (eg when using multiple applications, when doing CPU-intensive tasks and using iTunes at the same time, etc.)?
The bug does not show up immediately with light load in Chrome (only a few tabs open). But anything heavier, and audio dropouts start. No idea whether it's a Chrome bug or OSX, but the problem started immediately after 10.9 update.
The issue is present after a fresh reboot with no other applications running than Chrome.
My Chrome version is now 33.0.1750.117, which should be the current one.
iTunes and Safari audio output is always fine.
I run VMWare Fusion 6 virtual machines often, but that doesn't seem affect the bug way or another. Also, I only installed VF6 long after updating to 10.9.
Audio in Windows or Linux Chrome running in a VF6 virtual machine is perfectly good.
Just tested again, the issue seems to only affect Chrome playing Macromedia Flash content. I don't have Flash player installed, only Chrome's internal PPAPI Flash player.
I think I'm just bothered by my perception that this Mavericks upgrade is being presented as a fix for an OS X security issue, rather than just offering a patch to Mavericks users.
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:
Nope. Well, at least I can verify the SHA1 sum displayed on the download page. Wait, no, that was served over HTTP, too.Okay, I'll follow Apple's instructions for checking the certificate fingerprint in the installer (http://support.apple.com/kb/ht5044). But that page (Last modified November 2011) displays a different fingerprint (9C864771 vs FA02790F)...and that fingerprint was also served over HTTP.
Gives up and opens the App Store.