# Epic Apple fail - Upgrade to iOS 7.0.6 **URL:** \ **Category:** NYSpeed Off Topic\ **Created:** [February 22, 2014, 7:21am UTC](https://forums.speedlife.net/t/epic-apple-fail-upgrade-to-ios-7-0-6/268346 "2014-02-22T07:21:40Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![LZ1](https://avatars.discourse-cdn.com/v4/letter/l/7ab992/32.png) [@LZ1](https://forums.speedlife.net/u/LZ1)\ **Post date:** [February 22, 2014, 7:21am UTC](https://forums.speedlife.net/t/epic-apple-fail-upgrade-to-ios-7-0-6/268346/1 "2014-02-22T07:21:40Z")
![https://scontent-b-ord.xx.fbcdn.net/hphotos-ash4/t1/1620866_10151911227070060_1538954390_n.jpg](https://scontent-b-ord.xx.fbcdn.net/hphotos-ash4/t1/1620866_10151911227070060_1538954390_n.jpg) **None computer people** Apply this patch quickly Apple screwed up causing big flaw in the way they deal with SSL **Nerds see below** [https://www.imperialviolet.org/2014/02/22/applebug.html](https://www.imperialviolet.org/2014/02/22/applebug.html) "Yesterday, Apple pushed a rather spooky [security update](http://support.apple.com/kb/HT6147) for iOS that suggested that something was horribly wrong with SSL/TLS in iOS but gave no details. Since the answer is [at the top](https://news.ycombinator.com/item?id=7281378) of the Hacker News thread, I guess the cat’s out of the bag already and we’re into the misinformation-quashing stage now.So here’s the Apple bug: static OSStatus SSLVerifySignedServerKeyExchange(SSLContext \*ctx, bool isRsa, SSLBuffer signedParams, uint8\_t \*signature, UInt16 signatureLen) { OSStatus err; _…_ ``` if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; ... ``` fail: SSLFreeBuffer(&signedHashes); SSLFreeBuffer(&hashCtx); return err; }(Quoted from [Apple’s published source code](http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c).) Note the two goto fail lines in a row. The first one is correctly bound to the if statement but the second, despite the indentation, isn’t conditional at all. The code will always jump to the end from that second goto, err will contain a successful value because the SHA1 update operation was successful and so the signature verification will never fail.This signature verification is checking the signature in a [ServerKeyExchange](https://tools.ietf.org/html/rfc5246#section-7.4.3) message. This is used in DHE and ECDHE ciphersuites to communicate the ephemeral key for the connection. The server is saying “here’s the ephemeral key and here’s a signature, from my certificate, so you know that it’s from me”. Now, if the link between the ephemeral key and the certificate chain is broken, then everything falls apart. It’s possible to send a correct certificate chain to the client, but sign the handshake with the wrong private key, or not sign it at all! There’s no proof that the server possesses the private key matching the public key in its certificate.Since this is in SecureTransport, it affects iOS from some point prior to 7.0.6 (I confirmed on 7.0.4) and also OS X (confirmed on 10.9.1). It affects anything that uses SecureTransport, which is most software on those platforms although_not_ Chrome and Firefox, which both use NSS for SSL/TLS. However, that doesn’t mean very much if, say, the software update systems on your machine might be using SecureTransport.I coded up a very quick test site at [https://www.imperialviolet.org:1266](https://www.imperialviolet.org:1266/). Note the port number (which is the CVE number), the normal site is running on port 443 and that _is_ expected to work. On port 1266 the server is sending the same certificates but signing with a completely different key. If you can load an HTTPS site on port 1266 then you have this bug.Because the certificate chain is correct and it’s the link from the handshake to that chain which is broken, I don’t believe any sort of certificate pinning would have stopped this. Also, this doesn’t only affect sites using DHE or ECDHE ciphersuites - the attacker gets to choose the ciphersuite in this case and will choose the one that works for them.Also, this doesn’t affect TLS 1.2 because there’s a different function for verifying the different ServerKeyExchangemessage in TLS 1.2. But, again, the attacker can choose any version that the client will accept. But if the client _only_ enables TLS 1.2 then it appears that would workaround this issue. Likewise, if the client only enabled the plain, RSA ciphersuites then there’s no ServerKeyExchange and that should also work around this issue. (Of the two, the former workaround is much more preferable.)Based on my test site, iOS 7.0.6 does fix the issue but OS X 10.9.1 is still affected.This sort of subtle bug deep in the code is a nightmare. I believe that it’s just a mistake and I feel very bad for whomever might have slipped in an editor and created it.Here’s a stripped down that code with the same issue: extern int f(); int g() { int ret = 1; ``` goto out; ret = f(); ``` out: return ret; } If I compile with -Wall (enable all warnings), neither GCC 4.8.2 or Clang 3.3 from Xcode make a peep about the dead code. That’s surprising to me. A better warning could have stopped this but perhaps the false positive rate is too high over real codebases? (Thanks to [Peter Nelson](https://twitter.com/_peterdn/status/437224206330523648) for pointing out the Clang does have -Wunreachable-code to warn about this, but it’s not in -Wall.)Maybe the coding style contributed to this by allowing ifs without braces, but one can have incorrect indentation with braces too, so that doesn’t seem terribly convincing to me.A test case could have caught this, but it’s difficult because it’s so deep into the handshake. One needs to write a completely separate TLS stack, with lots of options for sending invalid handshakes. In Chromium we have a patched version of [TLSLite](https://github.com/trevp/tlslite) to do this sort of thing but I cannot recall that we have a test case for exactly this. (Sounds like I know what my Monday morning involves if not.)Code review can be effective against these sorts of bug. Not just auditing, but review of each change as it goes in. I’ve no idea what the code review culture is like at Apple but I strongly believe that my colleagues, Wan-Teh or Ryan Sleevi, would have caught it had I slipped up like this. Although not everyone can be blessed with folks like them.Lastly, there was a lot of discussion yesterday that Apple missed checking the hostname in the certificate. It’s true thatcurl on the OS X command line oddly accepts HTTPS connections to IP addresses when the IP address isn’t in the certificate, but I can’t find that there’s anything more than that and Safari doesn’t have that problem." It’s going to be funny to find out how this got into the code base from a lot of twitter posts seems like just the extra fail was pushed at one point so maybe it was NSA intentional :lol: ---
**Author:** ![boxxa](https://yyz2.discourse-cdn.com/flex034/user_avatar/forums.speedlife.net/boxxa/32/5045_2.png) [@boxxa](https://forums.speedlife.net/u/boxxa)\ **Post date:** [February 24, 2014, 7:13am UTC](https://forums.speedlife.net/t/epic-apple-fail-upgrade-to-ios-7-0-6/268346/2 "2014-02-24T07:13:27Z")
Apple issues its SSL patch via SSL. ---
**Author:** ![ubengineering](https://yyz2.discourse-cdn.com/flex034/user_avatar/forums.speedlife.net/ubengineering/32/5171_2.png) [@ubengineering](https://forums.speedlife.net/u/ubengineering)\ **Post date:** [February 24, 2014, 8:13am UTC](https://forums.speedlife.net/t/epic-apple-fail-upgrade-to-ios-7-0-6/268346/3 "2014-02-24T08:13:39Z")
I understand none of this -\_- But my iOs update downloaded flawlessly ---
**Author:** ![boxxa](https://yyz2.discourse-cdn.com/flex034/user_avatar/forums.speedlife.net/boxxa/32/5045_2.png) [@boxxa](https://forums.speedlife.net/u/boxxa)\ **Post date:** [February 24, 2014, 8:30am UTC](https://forums.speedlife.net/t/epic-apple-fail-upgrade-to-ios-7-0-6/268346/4 "2014-02-24T08:30:51Z")
> [@ubengineering](#): > > I understand none of this -\_- > > But my iOs update downloaded flawlessly The code is run when it verifies a certificate on a website. With the two goto statements, the second one will always hit and never return a invalid cert opening the door to some hacking and man in the middle attacks. It still blows my mind how something like this got into the code base. Not being able to validate a certificate means that you browsing the web and going to your banking site will give you no guarantee that you are actually on the real site or a fake site. ---
**Author:** ![boardjnky4](https://avatars.discourse-cdn.com/v4/letter/b/96bed5/32.png) [@boardjnky4](https://forums.speedlife.net/u/boardjnky4)\ **Post date:** [February 24, 2014, 8:34am UTC](https://forums.speedlife.net/t/epic-apple-fail-upgrade-to-ios-7-0-6/268346/5 "2014-02-24T08:34:00Z")
> [@boxxa](#): > > The code is run when it verifies a certificate on a website. With the two goto statements, the second one will always hit and never return a invalid cert opening the door to some hacking and man in the middle attacks. It still blows my mind how something like this got into the code base. > > Not being able to validate a certificate means that you browsing the web and going to your banking site will give you no guarantee that you are actually on the real site or a fake site. Agreed, at first glance it seems to me that this should have been caught in testing. Apple typically does a good job at the QA side of things, so this surprises me. ---
**Author:** ![ProgRocker](https://yyz2.discourse-cdn.com/flex034/user_avatar/forums.speedlife.net/progrocker/32/5434_2.png) [@ProgRocker](https://forums.speedlife.net/u/ProgRocker)\ **Post date:** [February 24, 2014, 8:59am UTC](https://forums.speedlife.net/t/epic-apple-fail-upgrade-to-ios-7-0-6/268346/6 "2014-02-24T08:59:00Z")
Updated two iPads at work so far…Love Apple COnfigurator ---
**Author:** ![Gus](https://yyz2.discourse-cdn.com/flex034/user_avatar/forums.speedlife.net/gus/32/5112_2.png) [@Gus](https://forums.speedlife.net/u/Gus)\ **Post date:** [February 24, 2014, 9:39am UTC](https://forums.speedlife.net/t/epic-apple-fail-upgrade-to-ios-7-0-6/268346/7 "2014-02-24T09:39:50Z")
[https://www.us-cert.gov/ncas/current-activity/2014/02/21/Apple-Releases-Security-Updates-iOS-devices-and-Apple-TV](https://www.us-cert.gov/ncas/current-activity/2014/02/21/Apple-Releases-Security-Updates-iOS-devices-and-Apple-TV) ---
**Author:** ![boardjnky4](https://avatars.discourse-cdn.com/v4/letter/b/96bed5/32.png) [@boardjnky4](https://forums.speedlife.net/u/boardjnky4)\ **Post date:** [February 24, 2014, 10:29am UTC](https://forums.speedlife.net/t/epic-apple-fail-upgrade-to-ios-7-0-6/268346/8 "2014-02-24T10:29:08Z")
> **[goto](https://xkcd.com/292/)** > > Neal Stephenson thinks it's cute to name his labels 'dengo' ---
**Author:** ![LZ1](https://avatars.discourse-cdn.com/v4/letter/l/7ab992/32.png) [@LZ1](https://forums.speedlife.net/u/LZ1)\ **Post date:** [February 24, 2014, 10:33am UTC](https://forums.speedlife.net/t/epic-apple-fail-upgrade-to-ios-7-0-6/268346/9 "2014-02-24T10:33:34Z")
I wonder how much the NSA paid to have someone add that one line :lol: ---
**Author:** ![Gus](https://yyz2.discourse-cdn.com/flex034/user_avatar/forums.speedlife.net/gus/32/5112_2.png) [@Gus](https://forums.speedlife.net/u/Gus)\ **Post date:** [February 24, 2014, 11:30am UTC](https://forums.speedlife.net/t/epic-apple-fail-upgrade-to-ios-7-0-6/268346/10 "2014-02-24T11:30:39Z")
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; [#added](http://www.nyspeed.com/usertag.php?do=list&action=hash&hash=added) by NSA to break this function and make man in the middle attacks against IOS users easier. if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; ---
**Author:** ![LZ1](https://avatars.discourse-cdn.com/v4/letter/l/7ab992/32.png) [@LZ1](https://forums.speedlife.net/u/LZ1)\ **Post date:** [February 24, 2014, 12:09pm UTC](https://forums.speedlife.net/t/epic-apple-fail-upgrade-to-ios-7-0-6/268346/11 "2014-02-24T12:09:15Z")
This also applies to OSX 🙂 ---
**Author:** ![ProgRocker](https://yyz2.discourse-cdn.com/flex034/user_avatar/forums.speedlife.net/progrocker/32/5434_2.png) [@ProgRocker](https://forums.speedlife.net/u/ProgRocker)\ **Post date:** [February 24, 2014, 12:20pm UTC](https://forums.speedlife.net/t/epic-apple-fail-upgrade-to-ios-7-0-6/268346/12 "2014-02-24T12:20:52Z")
Yeah I’ve seen security guys advise basically not using anything in OSX until it’s fixed. Already man in the middle attacks Sent from my MotoX using Tapatalk ---
**Author:** ![boardjnky4](https://avatars.discourse-cdn.com/v4/letter/b/96bed5/32.png) [@boardjnky4](https://forums.speedlife.net/u/boardjnky4)\ **Post date:** [February 24, 2014, 12:39pm UTC](https://forums.speedlife.net/t/epic-apple-fail-upgrade-to-ios-7-0-6/268346/13 "2014-02-24T12:39:31Z")
I think that’s a bit overboard. Though, as far as browsing the web goes, I would stay away from Safari and use Chrome, Firefox or Opera. ---
**Author:** ![LZ1](https://avatars.discourse-cdn.com/v4/letter/l/7ab992/32.png) [@LZ1](https://forums.speedlife.net/u/LZ1)\ **Post date:** [February 24, 2014, 12:59pm UTC](https://forums.speedlife.net/t/epic-apple-fail-upgrade-to-ios-7-0-6/268346/14 "2014-02-24T12:59:03Z")
> [@boardjnky4](#): > > I think that’s a bit overboard. Though, as far as browsing the web goes, I would stay away from Safari and use Chrome, Firefox or Opera. Tons of apps use the SSL support inside OSX. ---
**Author:** ![boardjnky4](https://avatars.discourse-cdn.com/v4/letter/b/96bed5/32.png) [@boardjnky4](https://forums.speedlife.net/u/boardjnky4)\ **Post date:** [February 24, 2014, 1:13pm UTC](https://forums.speedlife.net/t/epic-apple-fail-upgrade-to-ios-7-0-6/268346/15 "2014-02-24T13:13:59Z")
Yeah, i realize that. But in most cases folks won’t be able to stay off their computers until it’s patched. IF YOU CAN, you should isolate your work to non-Apple apps. eg. Use OWA/Gmail/Acme Webmail through Firefox rather than Apple Mail/Calendar. Use Twitter website instead of app. You get the idea. ---
**Author:** ![ubengineering](https://yyz2.discourse-cdn.com/flex034/user_avatar/forums.speedlife.net/ubengineering/32/5171_2.png) [@ubengineering](https://forums.speedlife.net/u/ubengineering)\ **Post date:** [February 24, 2014, 1:48pm UTC](https://forums.speedlife.net/t/epic-apple-fail-upgrade-to-ios-7-0-6/268346/16 "2014-02-24T13:48:40Z")
> [@boxxa](#): > > The code is run when it verifies a certificate on a website. With the two goto statements, the second one will always hit and never return a invalid cert opening the door to some hacking and man in the middle attacks. It still blows my mind how something like this got into the code base. > > Not being able to validate a certificate means that you browsing the web and going to your banking site will give you no guarantee that you are actually on the real site or a fake site. Ah okay, I see what you mean, at my work it always presents a certificate screen before getting on their wifi ---
**Author:** ![boxxa](https://yyz2.discourse-cdn.com/flex034/user_avatar/forums.speedlife.net/boxxa/32/5045_2.png) [@boxxa](https://forums.speedlife.net/u/boxxa)\ **Post date:** [February 25, 2014, 6:04am UTC](https://forums.speedlife.net/t/epic-apple-fail-upgrade-to-ios-7-0-6/268346/17 "2014-02-25T06:04:32Z")
> [@ubengineering](#): > > Ah okay, I see what you mean, at my work it always presents a certificate screen before getting on their wifi Basically because that is a self signed one. The browser and device knows it is encrypted but no guarantee the site is what you think it is. Think of this same problem for a banking website… ---
**Author:** ![LZ1](https://avatars.discourse-cdn.com/v4/letter/l/7ab992/32.png) [@LZ1](https://forums.speedlife.net/u/LZ1)\ **Post date:** [February 25, 2014, 11:55am UTC](https://forums.speedlife.net/t/epic-apple-fail-upgrade-to-ios-7-0-6/268346/18 "2014-02-25T11:55:27Z")
OSX update is out ---
**Author:** ![ProgRocker](https://yyz2.discourse-cdn.com/flex034/user_avatar/forums.speedlife.net/progrocker/32/5434_2.png) [@ProgRocker](https://forums.speedlife.net/u/ProgRocker)\ **Post date:** [February 25, 2014, 12:25pm UTC](https://forums.speedlife.net/t/epic-apple-fail-upgrade-to-ios-7-0-6/268346/19 "2014-02-25T12:25:52Z")
New One > **[New iOS flaw makes devices susceptible to covert keylogging, researchers say](https://arstechnica.com/information-technology/2014/02/new-ios-flaw-makes-devices-susceptible-to-covert-keylogging-researchers-say/)** > > Proof-of-concept app in Apple's App Store sent keystrokes to remote server.