Are 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?
About the security content of iOS 7.0.6
81–90 of 155 posts
Re: About the security content of iOS 7.0.6
#82So, was this plus automatic updates over SSL one of the ways the NSA could access "any iOS device"?
Potentially. 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.
They'd also need access to Apple's private keys.
Re: About the security content of iOS 7.0.6
#83Earlier quoted context omitted.
Take a look at 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).
Here's a diff of that file from OS X 10.8.5 (Security-55179.13) to 10.9 (Security-55471): https://gist.github.com/alexyakoubian/9151610/revisions Check line 631. Appears seemingly out of nowhere.
Good find!
But, are you sure the 10.8.5 (-55179.13) version isn't in some sense a later, patched maintenance branch compared to a 10.9 (-55471) that might have been frozen earlier? The release dates are very close (~2013-10-03 for 10.8.5; ~2013-10-22 for 10.9), and they might have already been separate branches.
(Is there a 10.8.4 version to compare?)
Re: About the security content of iOS 7.0.6
#84As 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 ta…
Take a look at 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).
(Spoiler) This is another reason why you should never use if statements without curly braces.
Thanks for the hint. It was amusing to spot the actual bug.
Re: About the security content of iOS 7.0.6
#85Re: About the security content of iOS 7.0.6
#86Adam Langley has written up the details of the issue here:
https://www.imperialviolet.org/2014/02/22/applebug.html
Re: About the security content of iOS 7.0.6
#87Earlier quoted context omitted.
Here's a diff of that file from OS X 10.8.5 (Security-55179.13) to 10.9 (Security-55471): https://gist.github.com/alexyakoubian/9151610/revisions Check line 631. Appears seemingly out of nowhere.
Good find! But, are you sure the 10.8.5 (-55179.13) version isn't in some sense a later, patched maintenance branch compared to a 10.9 (-55471) that might have been frozen earlier? The release dates are very close (~2013-10-03 for 10.8.5; ~2013-10-22 for 10.9), and they might have already been separate branches. (Is there a 10.8.4 version to compare?)
Good point. I just checked that file ever since it was open-sourced in 10.8 and it stays exactly the same throughout all of 10.8.x (10.8 - 10.8.5) and only changes in 10.9. (You can check for yourself here: http://opensource.apple.com/)
It doesn't seem like what you said is the case here but obviously we're still missing changesets that may have been committed between 10.8.5 (Security-55179.13) and 10.9 (Security-55471). It'd be really interesting to do a git-blame on that file.
EDIT: Nevermind, that file wasn't open-sourced in 10.8. It's actually really old. (Look for directories starting with libsecurity_ssl in pre-10.8 OS X versions.) Didn't find anything particularly interesting in the old versions though.
Re: About the security content of iOS 7.0.6
#88This 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.
Indeed. 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.
Because 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.)
Re: About the security content of iOS 7.0.6
#89Earlier quoted context omitted.
Take a look at 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).
Here's a little bit of a conspiracy theory for you. There's an old saying: "there are no coincidences on Wall Street". Not with the amounts of money that are involved. I think something similar should apply to critical security code. This reminds me of when someone tried to add the following to the Linux kernel: if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) retval = -EINVAL; Oops, is that "uid == 0", or i…
How could this not happen in Python?
Re: About the security content of iOS 7.0.6
#90Just 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[...]