Show HN: Check if your browser is vulnerable to the Apple SSL bug | Hacker News Reader

Show HN: Check if your browser is vulnerable to the Apple SSL bug

gotofail.com

118 pointscantfindmypass68 comments

Why the hell would Apple publish the vulnerability & fix for iOS without a concurrent update to OS X?!

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.

How hard is it to get the patch done? Isn't it, like, removing one line?

Yes, removing one line would fix it.

It became widely known outside of Apple due to the iOS patch.

How do you know they hadn't already seen it exploited in the wild?

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.

And having the source code available made that even easier.

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 deployment on iOS was not very active either. I learned about the 'bug' through online sources and I had to initiate the iOS update myself.

OSX 10.8.5 here, Safari not vulnerable according to the site

This bug was introduced in Mavericks.

Can't say I'm surprised

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.

This article claims that you can grep for the version number using otool and if it's not present the binary uses a different version of the library.

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.

Many apps use WebKit and are therefore affected too. It is in particular obvious for special purpose browsers like Mailplane.

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.

What a delightful idiom. I had to look it up.

https://en.wikipedia.org/wiki/Babes_in_the_Wood

Actually this demonstrates the opposite - this vulnerability has just been patched for half a billion people with no effort on their part.

Apple still hasn't released a fix for OS X...

Do you presume they won't?

/facepalm

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 patch doesn't need to be reverse engineered to discover that - the documentation alone and a quick test is enough.

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.

As if your question was any better.

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.

You can already do this here - https://www.imperialviolet.org:1266/

On OSX Firefox and Chrome fail and Safari happily loads it. Yay for not using system crypto libraries.

I started making this before agl released that, though he had that up before I finished.

Also, upon closer inspection, mine actually works differently from agl's.

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.

Chrome uses its own updater which presumably uses the same non-vulnerable SSL implementation as the rest of the program.

Doesn't matter, the system updater can blow away Chrome or anything else.

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.

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.

Yes, Little Snitch can help Safari pass this browser test (the unusual port was a red flag for me).

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?

No OS X patch is available yet. :-(

Chrome/Firefox shouldn't be vulnerable.

Chrome on iOS also seems safe

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?

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

Safari on 3GS running iOS 6 is vulnerable; chrome on the same device is not vulnerable

Safari under 6.1.3 is vulnerable, according to this site (I just tested my old iPhone)

There is a patch available for iOS 6 as well.

iPod 4g, 6.1.5. Vulnerable.

For HTTPS clients that don't execute Javascript (e.g. curl), GET https://gotofail.com:1266/

You'll need to request the image directly:

    curl "https://gotofail.com:1266/test.png"

curl on OS X 10.9.1 fetches the image without complaint, while curl on Debian is correctly reporting an RSA padding check error.

OSX 10.8.4 fails correctly. Was this bug introduced with Mavericks?

Yes, the bug is a regression introduced in Mavericks.

Safari fails on 10.9.1.

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

My web logs show lots of systems identifying as 10.9.2 pulling the test image from the bad server.

No, it isn't. It is still affected in the latest 10.9.2 builds.

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

1: http://pastebin.com/AZ38WYaB

That is a different bug.

OS X 10.7.5 passes; y'all should downgrade ;-)

why does it say my browser is vulnerable? Using Ucbrowser on lumia.

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 am now for informational purposes linking to the OS X patch released by i0n1c.

http://www.sektioneins.de/en/blog/14-02-22-Apple-SSL-BUG.htm...

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.

...

nope, saying that there is a page to check for an upcoming solution. Stating that there is nothing to do for now anyways.

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.

You're doing fine, this guy is just bikeshedding. Thanks for the tool, it certainly helped me.

I would be totally happy to put a proper stylesheet and some better copy together if someone wants to send me that (put it in a gist maybe?)

Reply on news.ycombinator.com