I'm seeing a positive (yes the bug is there) on all my Apple devices, including my OSX laptops - laptop sees the bug IF and only IF I browse using Safari. Chrome and FF browse to your page fine on the laptop.
I've not seen any information about fixing this issue on OSX. Have I just missed it in the noise about the iOS fix?
I don't know - I can't imagine that nobody on their security team pointed out that someone would promptly reverse engineer the patch and figure out that OS X is also vulnerable.
It's common security practice to release the exploit before the bug is patched in the OS. Oh wait, no, the opposite of that. Unless you're Apple. I'm very angry.
Presumably because the vulnerability is already known outside of Apple, and it's better not to hold back the iOS patch while they get the OSX patch done.
I haven't upgraded to Mavericks, and I haven't been able to replicate the bug. I've been applying other updates, everything except Mavericks, all along.
The reason I'm in 1.8.5 is because I upgraded to Mavericks, but one of their updates forced me to recover from Time Machine (which wasn't as smooth as I expected)
So if you're on Mavericks and left hanging, there are some evasive actions you can take.
As others have pointed out, Firefox and Chrome are not vulnerable. But what else may be relying on the system SSL implementation? Your IM client? Various software updaters? Dropbox? Skype? Etc.
Rather than guess, I'm whitelisting only the things I trust. I'm using the pf firewall to block all outbound connections other than DNS and SSH, using SSH to open a SOCKS proxy tunnel, and configuring Firefox to use the proxy (not via the system proxy settings -- via Firefox's own proxy config, so other apps don't know about it and can't get out).
A simpler solution for those who want to buy a commercial product would be to install Little Snitch and start with a completely empty list of approved apps, then turn on only Firefox.
>But what else may be relying on the system SSL implementation? Your IM client? Various software updaters? Dropbox? Skype? Etc.
Mail seems like a huge concern. I use two-factor on my google account, but that's not worth much when SSL doesn't work. For the time being, at least there's webmail + Firefox.
Can anyone confirm this on an iOS 6 device? I don't have of those anymore. Good news is iPad running 5.1.1 is not affected, which almost leads me to believe this vuln was introduced with iOS 7
It's becoming quite a chore to keep your computer and online accounts secure. I'm in the industry; anyone who is not is probably a babe in the woods these days.
That's a totally unhelpful comment. You imply that you know something that should be obvious and you think it's more helpful to be condescending than to contribute what you think.
The issue is that Apple's security engineers must have realized that there was a good chance someone would reverse engineer the patch, and from there find out the OS X is also vulnerable.
The difference between your comment and the conversation you have interjected it into is that you are being unhelpful and insulting on purpose, whereas there is room to resolve misunderstanding in the former case as you can see from the followup.
Thanks for showing us what kind of person you are.
Using the program Little Snitch on OS X 10.8 now to block everything except Firefox (recommended by u/ef4 here)- successfully helped Safari pass this browser test.
Can anyone else comment on if this is a decent solution?
I don't think 10.8 has the vulnerability. At least my MBP with 10.8 doesn't appear to have it. Both of the test URLs from HN had the desired behavior in Safari on that machine (ie they blocked content / didn't establish a connection).
EDIT: I'm not using Little Snitch or anything other than the builtin OSX firewall.
I can confirm that this is fixed in 10.9.2 (Since the first build of it). From the looks of things (and some friends in the Mavericks dev group), the final 10.9.2 should be dropping very soon
No...Not as far as I can tell. Attempting to connect over the bare IP address to an SSL site results in a curl error[1]. Whereas under 10.9.1 its allowed
I get the red "PATCH IMMEDIATELY" in safari, where is the patch???
after a bit of research this looks like a good old UX fail since there is no patch yet anyways. Don't write something in red if there is no path to a solution.
I'm not checking for Safari vs OS X. I'm not sure what else to say to vulnerable OS X users - there is not really any effective mitigation besides turning the computer off.
Yeah, if there's no path to a solution, the text should say "Your computer is correctly following the undesired behavior described in HT6147" in a soothing green color.
I use a filtering proxy which uses OpenSSL and it just reports "socket error" in the log and retries the connection around a dozen times before it gives up, so it seems I'm not vulnerable; non-Apple software isn't affected by this?
Anyone who thinks Chrome and Firefox are safe from this bug doesn't understand the issue. SecureTransport is used for updating software. So an attacker could trick you into installing a malicious update to Chrome, FireFox, or for that matter anything on your system. They could even slip in malware under the guise of a patch that purportedly fixes this bug. Using alternative browsers does NOT completely protect you.
Yes, I suppose that's true. However, I believe OS X's software update requires packages signed by Apple and doesn't simply trust the integrity provided by SSL, so I don't think that can happen.
That makes it slightly harder. Still, Apple will sign anything that is successfully submitted to the App Store for approval, right? So you just need to slip a single trojan past their approval process. Normally, the transport layer provides an important second level of defense: a victim would have to consciously choose to install YOUR program in order to get hacked. That doesn't work anymore when the security of the transport layer is compromised. Now anything that you install from the App Store could be surreptitiously compromised. Better hope that Apple's signature revocation infrastructure is sound.
All new App Store apps require sandboxing now, so as long as Apple's sandbox is tight (not a given, but it's supposed to be) then you can't do anything harmful. Apple won't sign anything you give the that isn't sandboxed.
The updater for Apple's own stuff obviously doesn't have this constraint, but it should involve a different signing key than the one used for third-party apps.
70 comments
[ 5.2 ms ] story [ 139 ms ] threadI've not seen any information about fixing this issue on OSX. Have I just missed it in the noise about the iOS fix?
Chrome/Firefox shouldn't be vulnerable.
On OSX Firefox and Chrome fail and Safari happily loads it. Yay for not using system crypto libraries.
Also, upon closer inspection, mine actually works differently from agl's.
The reason I'm in 1.8.5 is because I upgraded to Mavericks, but one of their updates forced me to recover from Time Machine (which wasn't as smooth as I expected)
As others have pointed out, Firefox and Chrome are not vulnerable. But what else may be relying on the system SSL implementation? Your IM client? Various software updaters? Dropbox? Skype? Etc.
Rather than guess, I'm whitelisting only the things I trust. I'm using the pf firewall to block all outbound connections other than DNS and SSH, using SSH to open a SOCKS proxy tunnel, and configuring Firefox to use the proxy (not via the system proxy settings -- via Firefox's own proxy config, so other apps don't know about it and can't get out).
A simpler solution for those who want to buy a commercial product would be to install Little Snitch and start with a completely empty list of approved apps, then turn on only Firefox.
Mail seems like a huge concern. I use two-factor on my google account, but that's not worth much when SSL doesn't work. For the time being, at least there's webmail + Firefox.
http://www.theregister.co.uk/2014/02/23/apple_mac_os_x_10_9_...
Latest Dropbox (v2.6.5), Adium, and Skype are fine according to this test. Most of Apple's software appears vulnerable however.
I'm not at all sure if this test is definitie however.
https://en.wikipedia.org/wiki/Babes_in_the_Wood
The unknown factor which makes rlu's comment so ignorant, is that we don't know whether the vulnerability is already known and being exploited.
If so, then not delaying the iOS patch is the correct call.
Thanks for showing us what kind of person you are.
Can anyone else comment on if this is a decent solution?
EDIT: I'm not using Little Snitch or anything other than the builtin OSX firewall.
1: http://pastebin.com/AZ38WYaB
http://www.sektioneins.de/en/blog/14-02-22-Apple-SSL-BUG.htm...
...
The updater for Apple's own stuff obviously doesn't have this constraint, but it should involve a different signing key than the one used for third-party apps.