13 ms·
About the security content of iOS 7.0.6
- randomstring 13y agoSounds like a classic Man-in-the-Middle (MITM) attack. Just a guess, but from the short description I suspect if you have control over DHCP you can get iOS to use your proxy. From there you can use something like mitmproxy ( http://mitmproxy.org/ http://mitmproxy.org/) to forge SSL certificates on the fly and intercept and decrypt SSL traffic without any warnings showing up on the iOS device.
- nwh 13y agoYou can do that but you'll be throwing certificate errors everywhere if they're self signed. By the sounds of it this is a bypass or method of getting around the CA altogether.
- chrismsnz 13y agoYes, normally certificate errors would be thrown. In this case Apple is not performing the domain validity checks on the presented cert. This allows an attacker that is performing an mitm attack to present a valid cert for another domain and establish an SSL connection with the victim.
- nwh 13y agoUgh, that's unbelievably awful.
- Fasebook 13y agolol oops
- nwh 13y agoDoes this contain patches for the jailbreak?
- britta 13y agoNo, apparently. See https://twitter.com/winocm/status/436923366147375104 https://twitter.com/winocm/status/436923366147375104 and https://twitter.com/winocm/status/436923608762695680 https://twitter.com/winocm/status/436923608762695680 for a jailbreak developer saying that it doesn't seem to fix any jailbreak bugs. He's not one of the developers of the iOS 7 jailbreak, but he knows what he's talking about.
- jayunit 13y agorelated: https://twitter.com/0x56/status/437055270942826496 https://twitter.com/0x56/status/437055270942826496
- deleted 13y ago[deleted]
- helper 13y agoWow, this sounds bad. It sure would be nice if Apple gave us a little bit more information, like when the bug was introduced and what exactly was not being verified. Until we get more information, you should assume the worst that all your IOS TLS traffic might be compromised.
- Greenisus 13y agoDoes anyone know if this is an issue at the Foundation API level (affecting any apps using NSURLConnection, for example) or if it's a Safari issue?
- acdha 13y agoIt's actually the reverse: Safari at least performs additional checks and does not appear to be affected, which would explain why this wasn't noticed faster. The big question is whether those checks are specific to Safari or to a higher-level API which most Cocoa apps would use.
- deleted 13y ago[deleted]
- rmoriz 13y agohttps://gist.github.com/rmoriz/fb2b0a6a0ce10550ab73 https://gist.github.com/rmoriz/fb2b0a6a0ce10550ab73 http://i.imgur.com/CoALymQ.png http://i.imgur.com/CoALymQ.png (i've not checked that on iOS or Apple TV just on OSX. Maybe it's another issue but the update description pretty much fits too well ;-)
- lawl 13y agoHoly shit! So they are really not checking the CN and knew it since 2013-11-28. I've lost the last bit of respect I had for apple (that was mostly building webkit) now. (I deleted my gp, because it's pretty much obsolete now with your full disclousure. Thanks!)
- tlrobinson 13y agoSo OS X as well as iOS?
- acdha 13y agoInteresting: bare IP addresses as you demonstrated but they do still appear to catch mismatched hostnames: https://213.133.107.227.xip.io/ https://213.133.107.227.xip.io/ Still an epic QA failure but much less of a threat if it doesn't allow arbitrary MITM attacks.
- nekitamo 13y agoLooks like they weren't checking the hostname in the certificate. This would allow anyone with a certificate signed by a trusted CA to do a MITM attack on iOS devices. Very very bad vulnerability.
- mikeash 13y agoIt seems to be a bit more than that, as I've verified that iOS 7.0.4 and Mac OS X 10.9.1 both refuse to connect to a server with a certificate for a different hostname. Sounds like verification is somehow different when connecting to a raw IP address. Safari treats that case differently, anyway: if I try to connect to a hostname that's different from what the certificate says, it simply refuses to establish the connection at all. If I try to connect to the raw IP address, it says the certificate is wrong, but gives me the choice to ignore the error and proceed anyway. Odd stuff.
- MichaelGG 13y agoMaybe due to lots of appliances that run HTTPS with a self-signed cert to "productname", but are often accessed via an IP?
- makomk 13y agoLooking at the code, this bug probably doesn't happen on connections which use TLS 1.2, which any properly configured server should support these days. (There's a seperate codepath for TLS 1.2 connections.) Note that this doesn't provide any protection against an attacker exploiting the vulnerability, since they get to choose what TLS version is used.
- noclip 13y agoIt's not just cURL. It's much bigger, and much worse. http://pastebin.com/Yb6pUvr6 http://pastebin.com/Yb6pUvr6
- teraflop 13y agoI don't know what you think that pastebin shows, but that error is not specific to OS X or to ssl.apple.com. OpenSSL is failing to validate the server certificate because you forgot to specify the -CAfile option. EDIT: I'm an idiot, see below.
- croikle 13y agoSo, I'm not sure about that one. Apparently s_client ignores the error and completes the connection because it's intended to be used for debugging. > Currently the verify operation continues after errors so all the problems with a certificate chain can be seen. As a side effect the connection will never fail due to a server certificate verify failure. https://www.openssl.org/docs/apps/s_client.html https://www.openssl.org/docs/apps/s_client.html https://www.mail-archive.com/openssl-users@openssl.org/msg71136.html https://www.mail-archive.com/openssl-users@openssl.org/msg71...
- noclip 13y agoThe s_client connection continues but should still report a verify error. On Linux: http://pastebin.com/QWpSrR5p http://pastebin.com/QWpSrR5p
- tlrobinson 13y agoHeh... "congrats to the Apple iOS team on adding SSL/TLS hostname checking in their latest update! very cool feature." https://twitter.com/will_sargent/status/436985812878491648 https://twitter.com/will_sargent/status/436985812878491648
- d0 13y agoComedic derision appreciated :) However this is a pretty damn serious oversight. I've just shut down my MacBook and picked up my ThinkPad.
- homakov 13y agoMac os is not vulnerable
- LawnGnome 13y agoIt appears to be, per https://gist.github.com/rmoriz/fb2b0a6a0ce10550ab73 https://gist.github.com/rmoriz/fb2b0a6a0ce10550ab73 (and my own testing on OS X 10.9.1).
- aroch 13y agoNot in 10.9.2 which is using the same curl version: http://pastebin.com/AZ38WYaB http://pastebin.com/AZ38WYaB
- homakov 13y agoWhy in release note of Apple it wasn't mentioned?
- lawnchair_larry 13y agoThe patch isn't ready for OS X. It will be in the next minor OS update. Bad Apple.
- F30 13y ago
- thibaut_barrere 13y agoIf I believe [1], 4% of all the iOS devices are still on versions earlier than 6, and will not be patched to this specific issue. This is pretty severe. I wonder (but presume not) if Apple is going to issue patches for earlier versions. [1] http://appleinsider.com/articles/13/12/31/ios-7-now-installed-on-78-of-active-apple-handheld-devices http://appleinsider.com/articles/13/12/31/ios-7-now-installe...
- mikeash 13y agoiOS 6 gets a fix too: http://arstechnica.com/apple/2014/02/apple-releases-ios-7-0-6-and-6-1-6-to-patch-an-ssl-problem/ http://arstechnica.com/apple/2014/02/apple-releases-ios-7-0-... Really old devices are probably out of luck, though. I think that would encompass the original iPhone, the 3G, the corresponding iPods Touch, and (probably most importantly) the first generation iPad. That's assuming, of course, that the bug is in iOS 4/5 in the first place, but if it dates back to iOS 6 I'd give good odds that it dates back farther still.
- crishoj 13y agoIf 96% of the installed base gets this patched more or less immediately, the situation is endlessly better than a similar situation would be for Android, given most manufacturers and operators' lack of interest in providing software updates.
- shawn-butler 13y agoDoesn't affect any app using SSL pinning. I have been trying to work on an implementation of TACK to mitigate headaches involved in pinning. Wish I had more free time. http://tack.io/index.html http://tack.io/index.html
- theboss 13y agoYeah the biggest problem with mobile devices I see that desktop applications have less often is crypto problems..It will get better as the time goes on.
- kryptiskt 13y agoThis is so bad that it is hard to imagine how it could have escaped notice until now, Apple really need to beef up their security competence. Lets hope that malevolent hackers were similarly asleep.
- sneak 13y agoIndeed. My first thought upon seeing this: "how in the FUCK did automated testing not catch this IMMEDIATELY!?" Absolutely terrifying that crypto safety is such a low QA priority that something like this could ever leave the building.
- giovannibajo1 13y agoBecause it's not a blatant regression, it's a complicate bug that requires a custom-patched TLS stack on the server to be explocited. As Adam Langley put it: > 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 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.)
- gojomo 13y agoExcept: ensuring that the server is signing with the right, certificate-certified private key is the major thing that TLS is supposed to provide. So no matter how strange or malicious the server-side stack would need to be... not having a test for such a deviation is a major oversight.
- gsnedders 13y agoThe really scary thing is that there is basically no good testsuite for SSL/TLS in existence. I would not be surprised if other stupid bugs showed up in other implementations given one…
- 13y ago
- computer 13y agoSo, was this plus automatic updates over SSL one of the ways the NSA could access "any iOS device"?
- hayksaakian 13y agoPotentially. This exploit was known to apple for some period of time, if NSA has access to the internal apple bug tracker, then they could certainly exploit the bug.
- hrrsn 13y agoThey'd also need access to Apple's private keys.
- gojomo 13y agoNot at all: that's the bug. It's not properly verifying that the other-end of a TLS session is the entity able to sign with the certificate-declared private-key.
- ef4 13y agoMost likely hrrsn was referring to code-signing keys. Even if you can successfully MITM a software update connection, iOS won't run your trojan unless it's got a valid signature. Of course the jailbreaking community knows well that there have been many ways around that...
- lawnchair_larry 13y agoNo.
- jtchang 13y agoHow do you not notice this? Maybe a lot of SSL interception is done with self signed certs and not ones that are signed by a valid CA?
- jtchang 13y agoHow do you not notice this? Maybe a lot of SSL interception is done with self signed certs and not ones that are signed by a valid CA?
- lstamour 13y agoOdd. Apple updated iOS 7 and iOS 6 but didn't update Secure Transport in iOS 5? I wonder if the bug was introduced between iOS 5 and 6. Background on Secure Transport: "At the bottom of the TLS stack on both iOS and Mac OS X is a component known as Secure Transport. Secure Transport maintains a per-process TLS session cache. When you connect via TLS, the cache stores information about the TLS negotiation so that subsequent connections can connect more quickly. The on-the-wire mechanism is described at the link below. http://en.wikipedia.org/wiki/Transport_Layer_Security#Resumed_TLS_handshake http://en.wikipedia.org/wiki/Transport_Layer_Security#Resume... "This presents some interesting gotchas, especially while you're debugging." More at: https://developer.apple.com/library/ios/samplecode/AdvancedURLConnections/Listings/Read_Me_About_AdvancedURLConnections_txt.html https://developer.apple.com/library/ios/samplecode/AdvancedU...
- raquo 13y agoApple do not support two versions of iOS back. They expect you to upgrade to a newer, slower version of iOS every time it's released. You won't be able to get the new iOS 6.1.6 on your iPhone unless it supports iOS 6 but not iOS 7, it is basically only for iPod 4th gen.
- tricolon 13y agoFWIW, the first time I went to https://notinthecert.imperialviolet.org https://notinthecert.imperialviolet.org in Mobile Safari on iOS 5.1.1, I got a "Cannot Verify Server Identity" error with Cancel, Details, and Continue buttons. After pressing Continue, it remembered my choice and did not alert me the second time.
- SyneRyder 13y agoSeems the bug was introduced in iOS 6. https://gotofail.com https://gotofail.com has been offering a test for the bug, and my iOS 5 devices pass the test.
- crishoj 13y agoBad as it may be, the fix Apple is pushing will reach roughly 95% of the installed base more or less immediately. I can't help wonder how much worse a similar situation would be for the Android ecosystem, with the poor update track record of operators and OEMs.
- UnoriginalGuy 13y agoGoogle would just push an updated Chrome app which soft fixes it for many use-cases.
- rodgerd 13y agoGruber, is that you?
- lstamour 13y agoAs it happens, Secure Transport (edit: on OS X) is open source. I just spent the last hour rummaging through source code ... It was later renamed to "libsecurity_ssl" when it landed on iOS. It's been around since OS X launched. They also have a folder with about four dozen regression tests and a test app, not that I've had the chance to inspect either that closely. The tarballs are spread across two folders in the tarballs index: Security (look for multi-MB file sizes) and libsecurity_ssl. The 5-digit numbers appear to be sequential revision IDs, any single-digit numbers seem historical. (E.g. libsecurity_ssl-6 is before libsecurity_ssl-10 rather than after libsecurity_ssl-55471.) It appears they haven't posted newer source than this. The most recent timestamp I could find was Oct 11, 2013 in 55471, which corresponds to 7.0 and my 10.9 system has the same version number for Security.framework -- same bundle version of 55471 for 10.9.1 aka 13A581. Previous version numbers don't appear to be as well-maintained. I don't expect a newer release to be posted until the next OS X release, as the source was only published under 10.9, not iOS. Additionally, there's no mention of iOS 7 on http://www.opensource.apple.com/ http://www.opensource.apple.com/ I couldn't easily find the bug without more to go on, because the code is spread across a few components and really, I'm not an expert in TLS. It appears to have been largely unchanged from 2000-2006 or so. TLS 1.2 brought quite a few changes, but it was neat to browse through the lines of "FIXME" and "TODO" comments, as well as various diffs between releases. And neat to see how much code today still goes back to 1999-2001, sometimes all they did was add a 'k' in front of a few variable names or delete the line in the first README saying the server code wasn't tested against Windows ;-) It sounds like when 10.9.2 is released, or at worst when 10.10 comes along, you'll see a new push of code to the opensource site. We can all diff 55471 against what comes next to see the changes. (If someone's already running 10.9.2 and its unaffected by the bug exhibited via curl, open /System/Library/Frameworks/Security.framework/Versions/Current/Resources/Info.plist and post the Bundle version.)
- pencilo 13y agoTake a look at http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c?txt http://opensource.apple.com/source/Security/Security-55471/l... specifically check the function SSLVerifySignedServerKeyExchange I leave the joy of spotting it to you. It is obvious and if you know c you'll see it(You don't need any knowledge of crypto).
- raptormissle 13y agoAnd to think these hypocritical idiots have the audacity to attack and disparage Android. To quote Phil "The Shil" Schiller - "be safe out there" Fix your leaky sieve first, Phil.
- pencilo 13y agoSSLVerifySignedServerKeyExchange in http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c?txt http://opensource.apple.com/source/Security/Security-55471/l... If you want to see my favorite SSL bug ever.
- jey 13y agoOh god, that's horrifying. Get ready to check certificate validity, then report success before actually checking validity!
- deleted 13y ago[deleted]
- gojomo 13y agoWow. Maybe the inconsistent indentation and brackets-optional formatting helped the bug both arrive and persist? Perhaps a preferable practice for security-conscious code would be to only set a success value after all checks have passed, rather than trust intervening logic to reset a default-success value, to an error-value, before return.
- hsivonen 13y agoAre there any known software updaters that rely only on Secure Transport hostname checking for update authenticiity? If you use NSS-based browsers exclusively on OS X, can you have been pwned via fake updates due to this bug?
- richm44 13y agoAdam Langley has written up the details of the issue here: https://www.imperialviolet.org/2014/02/22/applebug.html https://www.imperialviolet.org/2014/02/22/applebug.html
- Argorak 13y agoJust to be clear: /usr/bin/curl on Mavericks suffers from this problem: ~ /usr/bin/curl https://imperialviolet.org:1266 If you can see this message then[...] Keep that in mind when you download an installer using curl and pipe it to bash.
- js2 13y agoUnless curl uses Secure Transport on OS X, then it's a separate bug in curl/libcurl. Edit: apparently curl does use Secure Transport on OS X as of 7.27: http://curl.haxx.se/mail/lib-2012-06/0334.html http://curl.haxx.se/mail/lib-2012-06/0334.html http://daniel.haxx.se/blog/2012/06/28/darwin-native-ssl-for-curl/ http://daniel.haxx.se/blog/2012/06/28/darwin-native-ssl-for-...
- goobers 13y agoMaybe Apple should stick to hardware. Just sell me the beautiful hardware. I'll manage installing an OS that's 1. audited by a community of volunteers I generally trust and 2. can be audited (read: modified) by me: I can compile it from scratch. Apple's OS offerings provide neither 1 nor 2. But, go figure, Apple's OS offerings are based off of OS code that is both 1 and 2. Like a "Linux distro", Apple gives me a lot of stuff I do not want or need, and makes it very difficult if nt impossible to remove. I want a very minimal BSD or Plan9 OS running on my Apple hardware. And nothing more. Hardware we purchase should come with full documentation for writing drivers. If enough users demand this, maybe someday it will.
- Adirael 13y agoWhat's stopping you from installing FreeBSD or Apple's hardware? Everything has bugs, community volunteers are not infallible. It's good to be able to audit the things you use, but most people can't or won't do it.
- lisper 13y agoSince the source code is available, might it be possible to produce a hot patch to the binary so that those of us running Mavericks won't have to go through the next few days or weeks with our pants down? It would be a simple matter of finding the JMP instruction generated by the second GOTO and replacing it with no-ops. How hard could it be,at least for someone who actually knows their way around OS X binary file formats?