
About the security content of iOS 7.0.6 - davepeck
http://support.apple.com/kb/HT6147
======
tlrobinson
Heh...

"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
Comedic derision appreciated :)

However this is a pretty damn serious oversight.

I've just shut down my MacBook and picked up my ThinkPad.

~~~
homakov
Mac os is not vulnerable

~~~
LawnGnome
It 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).

~~~
F30
I'm able to reproduce your results with cURL. However, Safari on OS X
correctly shows a warning. Can anybody explain that?

~~~
gsnedders
cURL uses OpenSSL, Safari uses Apple's Secure Transport.

~~~
F30
That's not correct. The cURL version shipped with OS X uses SecureTransport.

------
lstamour
As 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
Take a look at
[http://opensource.apple.com/source/Security/Security-55471/l...](http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c?txt)

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).

~~~
alex1
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](https://gist.github.com/alexyakoubian/9151610/revisions)

Check line 631. Appears seemingly out of nowhere.

~~~
lectrick
Goto considered harmful, indeed!

~~~
stigi
Not much a problem of `goto` per se. Rather a problem with if conditions used
without code blocks.

Others might say it's a problem of whitespace insensitive languages ;)

~~~
kplaxmaster
Haha love the whitespace comment. This also makes you think of the static
source-code analysis done at Apple. Surely static tools would have picked this
up, no...?

~~~
subdigital
Clang currently does not warn about this, but I'd wager that Xcode will boast
a feature in the next version that detects dead code due to early
returns/gotos.

~~~
peternlewis
Clang may not warn about white space issues, but it certainly does warn about
unreachable code if -Wunreachable is on. This code would not compile in my
project because the unconditional goto leaves the following code unreachable.

------
kryptiskt
This 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
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.

~~~
giovannibajo1
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.)

~~~
gojomo
Except: 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
The 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…

------
lstamour
Odd. 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#Resume...](http://en.wikipedia.org/wiki/Transport_Layer_Security#Resumed_TLS_handshake)

"This presents some interesting gotchas, especially while you're debugging."
More at:
[https://developer.apple.com/library/ios/samplecode/AdvancedU...](https://developer.apple.com/library/ios/samplecode/AdvancedURLConnections/Listings/Read_Me_About_AdvancedURLConnections_txt.html)

~~~
tricolon
FWIW, 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.

------
nekitamo
Looks 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
It 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.

~~~
makomk
Looking 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.

------
richm44
Adam 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
Just 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
Unless 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-...](http://daniel.haxx.se/blog/2012/06/28/darwin-native-ssl-for-curl/)

------
computer
So, was this plus automatic updates over SSL one of the ways the NSA could
access "any iOS device"?

~~~
hayksaakian
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.

~~~
hrrsn
They'd also need access to Apple's private keys.

~~~
gojomo
Not 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
Most 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...

------
thibaut_barrere
If 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-
installe...](http://appleinsider.com/articles/13/12/31/ios-7-now-installed-
on-78-of-active-apple-handheld-devices)

~~~
crishoj
If 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.

------
randomstring
Sounds 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
You 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
Yes, 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
Ugh, that's unbelievably awful.

------
pencilo
SSLVerifySignedServerKeyExchange in
[http://opensource.apple.com/source/Security/Security-55471/l...](http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c?txt)

If you want to see my favorite SSL bug ever.

~~~
jey
Oh god, that's horrifying. Get ready to check certificate validity, then
report success before actually checking validity!

------
noclip
It's not just cURL. It's much bigger, and much worse.

[http://pastebin.com/Yb6pUvr6](http://pastebin.com/Yb6pUvr6)

~~~
croikle
So, 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/msg71...](https://www.mail-archive.com/openssl-
users@openssl.org/msg71136.html)

~~~
noclip
The s_client connection continues but should still report a verify error. On
Linux:

[http://pastebin.com/QWpSrR5p](http://pastebin.com/QWpSrR5p)

------
shawn-butler
Doesn'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
Yeah 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.

------
crishoj
Bad 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
Google would just push an updated Chrome app which soft fixes it for many use-
cases.

------
helper
Wow, 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.

------
goobers
Maybe 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
What'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
Since 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?

~~~
Someone
_" It would be a simple matter of finding the JMP instruction generated by the
second GOTO and replacing it with no-ops."_

Only if they used a truly stupid compiler. Chances are the unreachable code
behind it got optimized away.

~~~
lisper
Oh, right. (duh)

------
Greenisus
Does 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
It'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.

------
jtchang
How 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?

------
nwh
Does this contain patches for the jailbreak?

~~~
britta
No, 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.

------
hsivonen
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?

------
Fasebook
lol oops

