PSA: Upgrade your Apple shit, seriously.

I've spoken with a few people recently who, if they were even aware of the recent Apple security bug, don't seem to appreciate the magnitude of it.

It's basically the worst security bug in the history of security bugs.

If you are using a Mac running 10.7 or later, an iPhone 4 or later, or an iPad 2 or later, you have to upgrade your OS, right now.

If, like me, you've been putting off upgrading from iOS 6 to iOS 7, bummer. You don't have a choice now.

Here's a site that may test whether you're vulnerable.

Jeff Weinstein said, "Thanks, Apple, for making the Netscape Random Number Seed bug look minor."

Someone else said, "If you want a tour of of the Oval Office, just write 'Mr. President' on your t-shirt. They probably haven't upgraded yet."

It's egregious enough that enemy action isn't entirely out of the question.

Tags: , , , , ,

30 Responses:

  1. Walt N. says:

    They are making an iOS 6 update available, but only to devices with no iOS 7 upgrade path. Poor. I have been putting it off because iOS 7 makes the home screen look like CorelDraw threw up all over it.

    Does anyone know if the bug affects all SSL connections or is it restricted somehow, like those to an IP address instead of a hostname?

    • jwz says:

      As far as I can tell, there's no way to put that iOS 6 upgrade on an iPhone 5. You have to go to iOS 7.

      The bug affects every SSL connection. No certificate verification is happening. Anyone upstream of you can evesdrop and alter every SSL connection you make to any site, including running Apple's own Software Update.

      Exploiting CVE-2014-1266 with mitmproxy.

      • K. R. says:

        “Every” sounds like an overestimation: connections made using TLS version 1.2 are not affected, and so are those using some (rarely used) ciphers in the suite.

        For all intents and purposes, though, it may be safe to assume that 99% of SSL/TLS sessions these days use pre-1.2 TLS with ciphers that are affected.

        • ff says:

          "Every" is exactly right. A MITM attacker can choose the protocol version, you know.

          • K. R. says:

            Just as you can disable protocols and ciphers you deem insecure in your client.

            • ff says:

              I was not aware that iOS 6 provides any way to disable TLS 1.0. How do you do that? And isn't a huge majority of internet servers still on TLS 1.0?

      • AIUI Apple's software update packages are digitally signed, which does mean that an attacker can't spoof updates for you at least.

    • Glaurung says:

      "I have been putting it off because iOS 7 makes the home screen look like CorelDraw threw up all over it."

      There's a cydia tweak that fixes the vulnerability without upgrading (sslpatch), but you need to be jailbroken.

  2. FA says:

    There is an iOS 6 patch as of Feb 21st.

  3. ff says:

    Actually, if you're on 10.7 or 10.8 I think you're safe from this bug. Apparently it was introduced with 10.9.

    • jwz says:

      Maybe. HT6150 isn't particularly clear about that. It seems to say that at least 10.8.5 is vulnerable.

      • ff says:

        Those are different bugs, actually, this particular catastrophic SSL one was CVE-2014-1266 which is 10.9 only :)

        It's still incredibly bad. I'm sure a lot of people will stick with a buggy ios6 on ios7-capable devices and not understand the risk - and there's no 6.1.6 for them :(

      • tl says: indicates that 10.8.5 is safe from the main bug that got tech news attention. It may not be safe from the other vulnerabilities.

      • gotofail says:

        The gotofail bug is iOS 6/7 and OS X 10.9 only. There is a different bug in which the name on the certificate is not verified for an https URL that points to IP address instead of a hostname.

  4. Chris Davies says:

    What I don't understand is why they don't have tests for such a security critical component. Hell, I don't understand why they don't have tests for all components.

    I actually have maintained the TLS stack for a major commercial operating system. I wrote the whole test suite which basically amounted to a second, completely separate TLS stack, albeit a vastly simpler one designed to inject data in to the handshake of the production stack. It included a large array of certificates to simulate the diverse sorts of client and server certs that can live out there in the wild. If someone broke the certificate verification without breaking the corresponding test at the same time, it would be instantly caught. Anyone fiddling about with the tests would (hopefully) have to explain themselves in peer review.

    I can't imagine how poor your programming practices have to be to have no decent test coverage for something like this. If you can't even be bothered to test your own software, why not just use OpenSSL that actually does have a decent suite of tests? It boggles my mind.

    • jwz says:

      It really is boggling.

    • Based on the quality of their software in general, is it really so surprising?

    • Other jamie says:

      Or even run a test for unreachable code?

      Hell, I even run that on my bullshit, probably never going to use this again stuff, because it is such an obvious indication of a fuckup.

      • Ian Young says:

        XCode 6: now with 'Unreachable Code' inspections!

      • Ian says:

        Perhaps slightly less surprising given that apparently using Clang 3.3 with -Wall (enable all warnings) doesn't enable the Wunreachable-code ..warning.

        It must be some new definition of 'all' I wasn't previously aware of.

    • Bill says:

      > What I don't understand is why they don't have tests for such a security critical component

      > I wrote the whole test suite which basically amounted to a second, completely separate TLS stack

      I think you answered your own question.

    • ix says:

      Someone from the Chromium team indicated that the specific spot where the vulnerability was introduced makes it likely that tests missed it. Apparently his first order of business was to check if they test for this kind of thing. I'm going to assume Apple had tests and somehow their testers didn't think of their type of thing.

      I have heard in the past that compared to other software companies Apple's developer count is really low and you have to wonder whether that is impacting their ability to properly security test their sofware, but if someone who's job it is to secure a rival browser TLS implementation thinks it's likely he could've fucked it up too, I don't think it's fair to say that Apple has no testing at all.

    • lenny says:

      C-x h M-x indent-region

  5. Please calm down (but just a little). It's the worst security bug since... I dunno, last pwn2own? Think about it, which is worse?

    1) An attacker with active MITM can spoof SSL certs
    2) An attacker with active MITM or XSS on a web site you visit or access to your friend's Facebook/Twitter/whatever can run whatever code they like on your computer, including adding fake root certs, or just sniffing all your passwords, or whatever.

    Yes, breaking SSL is really, really bad. But there are far worse things.

  6. Josh says:

    Odd. My 10.5.8 "antique", Tenfourfox with https everywhere made it through the #gotofail test successfully.

    Security through obscurity?

    • Nick Lamb says:

      Was there a specific part of "10.7 or later" that made you think it applied to you even when just skimming Jamie's post (as others pointed out later it's actually 10.9 onwards that introduced this bug)? Likewise Tenfourfox is not Apple software, it uses (for better or worse, in this case better) Mozilla's TLS implementation not Apple's and isn't affected, though since you're running an obsolete unsupported operating system you probably have only wishful thinking for security anyway.

      Finally, for most people the gotofail site doesn't actually test anything, it just looks at the OS reported by your web browser's connection headers and guesses whether you're vulnerable. If you bother to lie to the site it'll give you a clean bill of health on a vulnerable OS version.

  7. lenny says:

    Oh what a coincidence! A similar bug with similar effects just happens to exist in linux too.