
On the Timing of iOS’s SSL Vulnerability and Apple’s ‘Addition’ to NSA’s PRISM - dieulot
http://daringfireball.net/2014/02/apple_prism
======
tptacek
This seems so silly to me, Jon.

The OSX/IOS SecureTransport TLS vulnerability is getting coverage because it's
easy for laypeople to understand. Any geek can look at a description of the
bug, or even the code itself, and say to themselves, "hey, I could exploit
that!". Because more people understand this bug than they would any other bug,
it paradoxically seems scarier.

The reality however is that the ease with which a bug can be exploited has
little to do with its impact. What matters is the feasibility of exploitation.
And in terms of feasibility, this bug is _less_ exploitable than the kinds of
bugs that are disclosed in every platform every month; it requires a specific
(common, but not universal) set of circumstances to escalate it to code
execution.

Matthew Green told a Reuters reporter yesterday that the TLS bug was "as bad
as could be imagined". He was also drinking†, which explains how he managed to
find a TLS validation bug worse than memory corruption, which is discovered
routinely in all platforms, and produces attacks that directly, instantly
hijack machines regardless of their configuration and the network they operate
on.

Vulnerabilities in TLS code are not all that unusual. We get a new one every
couple years or so. There was a vulnerability in the NSS False-Start code a
year ago --- it didn't get covered because (a) few people know what NSS is
(it's the TLS library for Firefox and Chrome) and (b) nobody knows or cares
about False-Start. Here's another example: NSS misparsed PKCS1v15 padding,
such that an e=3 RSA certificate could be forged --- anyone on the Internet
could run a small Python script to generate a certificate for any site.
Certificate chaining has broken within the last ~4 years ago. Again, no
coverage: what's e=3 RSA? How does chaining work?

Simple thought experiment: imagine if, instead of a missing-brace bug that
broke all of TLS, it was instead disclosed that NSS had a memory corruption
vulnerability in its PKCS1v15 parsing. Would there be a shitstorm in the media
and on Twitter? I doubt it: comparable bugs are found routinely without
shitstorms.

I don't know if NSA knew about this bug or didn't. If they did, I'm confident
that they exploited it; that's what they do. But ask yourself if you're sure
that NSS and SecureTransport and OpenSSL and SCHANNEL are free from the kinds
of memory corruption vulnerabilities that would allow NSA (and other organized
criminals) to hijack machines directly. You think _this_ is the bug they're
relying on?

† _No, really._

~~~
blazespin
Tptacek, it is scary because of exactly that -- it is so simple. How could
such a secure platform built by such a massively large cap tech company do
something so incredibly stupid in its most critical security stack.

If this trivial bug can happen and pushed into production .. Good lord,
anything can happen.

The foundation of our mobile economy has just been proven to be on very very
shaky legs.

~~~
tptacek
This is a comment that seems to suggest that it's abnormal for dumb bugs to
cause huge security problems. It is not. If the foundation of our economy is C
software security, well, hate to break it to you, but...

~~~
blazespin
It is absolutely abnormal for companies like Apple to release core security
bugs this shallow that could have been easily discovered by straightforward
unit tests and static analysis tools.

This is why it's a big deal.

~~~
f_salmon
The other reason why this is no big deal (anymore) is that the Snowden leaks
have shown that the NSA has total control over all iPhones.

Why should we even bother talking about bugs like this anymore? Pure
distraction.

~~~
kalleboo
> the Snowden leaks have shown that the NSA has total control over all iPhones

You mean: had total control over all the original iPhones that they could get
physical access to. (back when jailbreaking was extremely simple and common)

~~~
f_salmon
Where does the "physical access" part come from? And if that was the case, why
would it be impossible now?

One of the sources: [http://www.forbes.com/sites/erikkain/2013/12/30/the-nsa-
repo...](http://www.forbes.com/sites/erikkain/2013/12/30/the-nsa-reportedly-
has-total-access-to-your-iphone/)

~~~
kalleboo
From the slide on your very link: "The initial release of DROPOUTJEEP will
focus on installing the implant via close access methods. A remote
installation capability will be pursued in a future release."

Basically how it worked was they jailbroke your iPhone and installed spyware
on it. Is it quite likely that today, 7 years later, they have a remote 0day
to do the same? Absolutely. But there's no proof that "the NSA has total
control over all iPhones".

------
gojomo
Let's not ascribe all deviousness to the NSA!

Sneaking this in, and being the 1st (or only) group to know about it, would be
valuable to lots of amoral entities, from solo criminals up through state
actors. Simply being bold enough to use a bogus signing-key (different than
the one in the certificate you just showed) was enough to fool every iOS6/7
device for more than a year!

I'd personally hope that the NSA would be more subtle, and has a longer-term
interest in ensuring Apple products _seem_ secure. Other state actors or
criminal gangs would be more interested in a short-term benefit, and then
wouldn't mind that afterward Apple (and US tech in general) gets egg-on-their
face. That could be icing on the cake.

I hope Apple does a deep-dive on how this happened – not just "5 whys" but "50
paranoid whys" – including looking at the employee who made the change's
background and personal security practices.

What if the person it's traced to does not recall making that change? What if
they find evidence that systems designed to catch such a thing were themselves
subverted, such as different code shown to a reviewer, or build tools set to
suppress certain warnings? It might be a simple slip up... or a very, very
deep compromise that takes weeks or months to unwind.

Letting my paranoid imagination roam wild, recall a few years ago when Google
suddenly became very, very chilly towards China, after reports of some deep
compromises. My hunch is that Google perceived a threat so extreme – like an
attempt to hijack their auto-update mechanisms – that it resulted in an all-
new level of lockdown and resentful cold war. What if this is a similar
existentially-revelatory moment for Apple, with regard to some state actor?

~~~
judk
Your conspiracy theory is a bit too complicated. Here is how it works in
practice: Bad actor shows up (compromised employee, or vendor with system
access, whatever). Bad actor notices that code reviews are not required or a
reviewer can be buffaloed with a 10k line commit, and static analysis tools
aren't a commit hook, or employees don't lock their computers, or he has
access to scp a binary on to a production server, or dozens of possible
exploits that everyone knows about and is planing to fix eventually...

------
sneak
Unless I'm misunderstanding exactly what PRISM is, this bug seems like it
would only be useful for OTHER nsa data collection programs, not PRISM.

Unless, of course, we are now using the term PRISM to refer to all NSA
activities that we don't agree with.

Gruber should know better.

~~~
tptacek
We are definitely using the term PRISM that way.

~~~
vilhelm_s
You might be, but Gruber wasn't -- the evidence he linked to was a powerpoint
slide which was specifically about PRISM. Which means that it is not relevant
when trying to determine if NSA introduced this vulnerability or not.

------
0x0
To everyone claiming "it looks like a merge gone bad": That's a bit hard to
believe. There's no other changes around the extra goto, so it's pretty weird
for a duplicate line to appear like that out of nowhere. It's also incredibly
visible in any diff viewer, so how such a checkin could have gone in without
being noticed is just unfathomable.

~~~
tptacek
It's hard to believe if you pay no attention to bugs caused by code
refactorings, but easy to believe if you, for instance, saw the OpenBSD IPSEC
team refactor authentication checking on IPSEC packets out of the kernel by
accident, in almost the exact same manner as this bug.

~~~
lawnchair_larry
No, because the OpenBSD case was NSA as well (via NETSEC, who worked on the
OpenBSD IPSEC stack, and have since admitted to sneaking backdoors in). Exact
same MO, 15 years later!

(I don't actually believe this, but it was too convenient and amusing not to
call out.)

~~~
tptacek
I thought the NETSEC conspiracy theory was Angelos Keromytis working for the
FBI.

------
silvestrov
It's not the first time Apple has a bug with verifying the hostname of the
certificate.

In June 2010 I reported that Safari 4 did not check the last letter of the
hostname, so a certificate for example.de was accepted when accessing
example.dk, and it would accept cert for example.co.ug when accessing
example.co.uk

The real problem is that Apple did not add unit testing when they fixed the
problem in 2010. If they had, the goto bug would have been found.

~~~
mkempe
The "person" who made the "error" in the core code could have made a similar
"error" in the unit test.

~~~
PhantomGremlin
Yes, that would be quite the "coincidence", wouldn't it?

------
tyho
Why would the NSA put a backdoor in an open source component of iOS and OSX
when presumably, it would have been just as easy to put it in the closed
source part, where it would be much less likely to be found and even less
likely to ever be publicly exposed?

------
higherpurpose
Wrong. The only 3 options are these:

1) The NSA knew about it, and exploited it.

2) NSA itself planted it surreptitiously.

3) Apple, complicit with the NSA, added it.

Such a bug would've never lasted this long without NSA knowing about it. Even
if they didn't find it themselves, which seems unlikely, they would've bought
it from the exploit black market long before now. There are people who all
they do long is try to find exploits in the iPhone.

And as we know, if NSA _can_ do something, NSA _will_ do it. So they most
definitely took advantage of that "bug" and everyone's data that they could
get through it.

To me the more likely scenario is still that Apple cooperated with the NSA
here. The "adding to PRISM" at the same time this bug appear is _way_ too
coincidental.

~~~
mkempe
Further to 1) if the NSA fulfilled its mission and actually helped secure the
country against enemies, they would have immediately told Apple about the
security hole. Hence we're down to 2) and a modified 3) Apple, complicit with
the NSA, added or kept it.

------
prehkugler
> I see five levels of paranoia: ... 5. Apple, complicit with the NSA, added
> it.

While it seems _possible_ that Apple conspired with the NSA to add a security
hole in SecureTransport, I doubt it. According to sources in the article, this
bug was introduced in iOS6; and I haven't heard a mention of it until
yesterday, despite it being open-sourced
([http://opensource.apple.com/source/Security/Security-55471/l...](http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c)).

Since nobody was raging on the internet about this bug, I see it as a good-
faith effort by Apple to fix a bug that they've just discovered.

~~~
higherpurpose
Consider this: it was only at the end of December when Appelbaum showed some
documents about iPhones being hacked by the NSA, and it made a pretty big
splash in the media. I think it even forced Apple to respond at the time.
_Especially_ if this was open sourced, and everyone could see they fixed it,
they wouldn't _immediately_ try to plug the bug/backdoor after that piece of
news came out, especially with such a weird bug.

~~~
giovannibajo1
Those documents were about NSA bein able to plant a malware on a iPhone (1st
generation) when given physical access. I would say it has nothing to do with
this TLS bug

------
aidos
I also would go at least as far as #3 ( _The NSA knew about it, and exploited
it._ ). And it does seem a reasonable explanation for the prism slide update.

I only just heard about this bug a couple of hours ago. I can not for the life
of me fathom how this code was not tested. Surely this is a basic function of
the security code. You can test for it with a simple bit of js. If something
as important and easily testable as this is broken, what other subtle issues
are down there?

I, for one, no longer trust the Apple's software (I know that seems a bit
dramatic but I just don't enjoy using it anymore, on any level). Intentional
or not, this has all been handled very badly. Massive security hole, quietly
releases iOS update, doesn't offer update for their freaking desktop os.

~~~
ralfd
In theory yes. But Google Engineer Adam Langley wrote:

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

------
higherpurpose
> The Prism program collects stored Internet communications based on demands
> made to Internet companies such as Google Inc. and Apple Inc. under Section
> 702 of the FISA Amendments Act of 2008 to turn over any data that match
> court-approved search terms.

[https://en.wikipedia.org/wiki/PRISM_(surveillance_program)](https://en.wikipedia.org/wiki/PRISM_\(surveillance_program\))

"Demands made to the companies". It looks to me like PRISM was a voluntary
thing, even if the companies didn't know it was named PRISM.

If that's the case, and Apple's "bug" happened at the same time with their
_voluntary_ addition to PRISM, then the bug was actually a backdoor, and Apple
knew about it.

~~~
declan
Prism is as precisely as "voluntary" as the cops showing up with a search
warrant at 5am and asking you nicely to open up "voluntarily", because, well,
they have a nice 5.11 MiniRam Breaching Tool 50091 and your door looks very
pretty and it would really be a shame to have to knock it off its hinges. Yes,
that would be a real mess.

See what I wrote on this last summer:
[http://news.cnet.com/8301-13578_3-57588337-38/](http://news.cnet.com/8301-13578_3-57588337-38/)

------
daniel-cussen
I thought the date NSA was added to prism simply had to do with Steve Jobs
dying. It's the kind of thing I could see him refusing to cooperate with.

~~~
lern_too_spel
The date has to do when Apple had cloud services that more than a few people
outside the US used. There's no point simplifying data requests to a provider
that doesn't have any data they want.

------
rrggrr
Where is the patch for OSX Mavericks Apple? Patches aplenty for iOS yet it
appears Safari is still vulnerable.

~~~
d0
Exactly. My MacBook is now for sale. Back to my Lenovo T400.

Trust = gone.

Apple's policy of silence and denial don't cut it any more. At least Microsoft
use proper threat modelling, disclosure and mitigation processes, documented
KB articles and have literally tonnes of QA and test capacity. Not joking but
they have tens of thousands of machines in their test labs.

------
bandushrew
The thing that _really_ bites about this is the idea that the NSA could have
taken advantage of the vulnerability rather than alerting apple to it.

The idea that they are as fiercely hostile to the security of millions of
americans as taking advantage of the vuln would require, is absolutely
terrifying.

------
yeukhon
I am not sure if such post has any value to add to our current state of
affair. If this is not the bug they use to exploit iOS users, there are other
bugs. So what is the point of this article? Are we going to do a _witch hunt_
and blame the developers who either overlooked at the diff, or the developer
who happened to be an NSA mule?

I get it. NSA is behind everything. And at the end of the article, OP says
"[so] if this bug, now closed,2 is not what the NSA was exploiting, it means
there might exist some other vulnerability that remains open." So why are we
writing this article if there are other bugs?

Okay. I will give the credit and think about it: anyone could be NSA mule.
Anyone can contribute to your OSS and inject some clever code into your OSS
codebase. And we usually overlook security and just accept anyone's PR as long
as the code makes sense. Yeah, think about someone cleverly injecting a line
into your docker release or your openstack release last month.

So, the point is: be alert? Be aware of spy everywhere? This reminds me of a
scene in movie _Eden_. Bob, the corrupted federal Marshall, who was actually a
PIMP, once said to other marshals: "So who are you [looking for human
trafficking mules] looking for? The answer is everyone."

Hence, the main point is: trust is destroyed.

------
codezero
My own conspiracy theory is that these times match up where they adopt some
form of widespread XMPP. Google Talk, iMessage (2012), MS Messenger, etc...
and aligns with the recent talk of re-doing encryption in federated XMPP:
[https://github.com/stpeter/manifesto](https://github.com/stpeter/manifesto)

XMPP isn't just for chat, it's for video, server to server message passing,
status updates, etc...

------
terminus
From the article:

> NSA itself planted it surreptitiously.

> Apple, complicit with the NSA, added it.

Neither seems very likely given how visible the goto is. Something just a
little more subtle like a semicolon at the end of the if() clause might look
better.

Of course given how glaring it is, it could be a case of plausible
deniability: would we do something to stupid, so unsubtle.

~~~
ggreer
"A sneaky bug? Only the NSA could have pulled that off! An obvious bug? Only
the NSA would be so brazen in trying to throw us off their track!"

 _If the witch had led an evil and improper life, she was guilty; if she had
led a good and proper life, this too was a proof, for witches dissemble and
try to appear especially virtuous. After the woman was put in prison: if she
was afraid, this proved her guilt; if she was not afraid, this proved her
guilt, for witches characteristically pretend innocence and wear a bold front.
Or on hearing of a denunciation of witchcraft against her, she might seek
flight or remain; if she ran, that proved her guilt; if she remained, the
devil had detained her so she could not get away._ [1]

If you argue that an obvious bug is evidence of NSA involvement, then you must
also believe a subtle bug would be evidence _against_ NSA involvement. You
can't have it both ways.

1\. From Conservation of Expected Evidence
[http://lesswrong.com/lw/ii/conservation_of_expected_evidence...](http://lesswrong.com/lw/ii/conservation_of_expected_evidence/)

~~~
terminus
> If you argue that an obvious bug is evidence of NSA involvement, then you
> must also believe a subtle bug would be evidence against NSA involvement.
> You can't have it both ways.

Thanks for taking the argument to a mathematical plane. My reasoning was the
following:

P(is-involved) = P(is-involved|subtle)P(subtle) + P(is-
involved|subtle)P(~subtle)

Now, we know that 0 < P(is-involved) < 1\. Assuming that there have been past
instances of their involvement in both subtle and unsubtle bugs, I think my
argument where I can attach a probability of their involvement in both the
case was fair. Or do you think I missed something.

Note: I think I got it. Essentially your point is that given that I am using
the unsubtle-ty of the bug to argue both ways, implies that this variable
provides us no useful information and can be removed from the discussion.

Thanks for pointing out my muddy reasoning.

~~~
nicky0
Shouldn't it be

P(is-involved) = P(is-involved|subtle)P(subtle) + P(is-
involved|~subtle)P(~subtle)

------
blago
_“Never ascribe to malice that which is adequately explained by
incompetence.”_

Just for the record and off topic, this is known as the Hanlon's razor. It's
usually attributed to Robert J. Hanlon, not Napoleon Bonaparte.

------
bsder
While Apple may not have intentionally added this (and I'm a bit skeptical--
you have to shut off unreachable code and indentation systems to let this
through), they almost certainly intentionally _LEFT_ this in.

This is such an easy exploit that somebody found it and was using it. There is
no way that this was not spotted by Apple in the field.

------
yarou
I highly doubt that this particular bug was due to a shadowy government agency
or that type of collusion. It's more likely that someone fucked up, it can
happen to anyone. You have to look at it from a game-theoretic perspective.
Assuming there is collusion between Apple and NSA, it would at least __look__
intentional.

------
cdoxsey
I'm so sick of all this conspiracy theory nonsense. If PRISM means Apple
supplies data directly to the NSA there's no need for a MITM attack. I mean
what's the argument? Plausible deniability?

> Never attribute to malice that which is adequately explained by stupidity.

A programmer screwed up. It happens every day.

I'm reminded of Chesterton's madman:

>The madman’s explanation of a thing is always complete, and often in a purely
rational sense satisfactory. Or, to speak more strictly, the insane
explanation, if not conclusive, is at least unanswerable; this may be observed
specially in the two or three commonest kinds of madness. If a man says (for
instance) that men have a conspiracy against him, you cannot dispute it except
by saying that all the men deny that they are conspirators; which is exactly
what conspirators would do. His explanation covers the facts as much as yours.
Or if a man says that he is the rightful King of England, it is no complete
answer to say that the existing authorities call him mad; for if he were King
of England that might be the wisest thing for the existing authorities to do.
[...] Nevertheless he is wrong. But if we attempt to trace his error in exact
terms, we shall not find it quite so easy as we had supposed. Perhaps the
nearest we can get to expressing it is to say this: that his mind moves in a
perfect but narrow circle. A small circle is quite as infinite as a large
circle; but, though it is quite as infinite, it is not so large. In the same
way the insane explanation is quite as complete as the sane one, but it is not
so large. [...] If we could express our deepest feelings of protest and appeal
against this obsession, I suppose we should say something like this: "Oh, I
admit that you have your case and have it by heart, and that many things do
fit into other things as you say. I admit that your explanation explains a
great deal; but what a great deal it leaves out! Are there no other stories in
the world except yours; and are all men busy with your business? Suppose we
grant the details; perhaps when the man in the street did not seem to see you
it was only his cunning; perhaps when the policeman asked you your name it was
only because he knew it already. But how much happier you would be if you only
knew that these people cared nothing about you! How much larger your life
would be if your self could become smaller in it; if you could really look at
other men with common curiosity and pleasure; if you could see them walking as
they are in their sunny selfishness and their virile indifference! You would
begin to be interested in them, because they were not interested in you. You
would break out of this tiny and tawdry theatre in which your own little plot
is always being played, and you would find yourself under a freer sky, in a
street full of splendid strangers"

~~~
DennisP
So you're still deriding ideas like this as "conspiracy theory nonsense," even
after extensive documentation that the NSA is, in fact, surreptitiously
introducing security holes in software?

Personally I've adjusted my Bayesian priors a bit.

~~~
cdoxsey
Extensive documentation does not exist. It's all conjecture and speculation.

We know the NSA spies on foreigners, we know they have relationships with tech
companies to make that spying easier and therefore have access to all that
information. We don't the extent of domestic use. We know they collect phone
metadata. We know they have infiltrated software abroad, they deny having done
it domestically. There's just a whole lot we don't know.

Here's something I do know: the government is not infallible. In fact, just
the opposite. Sure Snowden revealed a lot about the NSA spying programs, but
he also revealed another salient fact: their background check process was a
joke. Like every other government agency they display an incredible degree of
incompetence.

Sleeper agents at Apple inserting bugs into code in order to bypass security
checks as part of some grand scheme to infiltrate the communications of
millions of Americans... it's not even a good idea on the face of it, but even
if they tried to pull this off they'd screw it up somewhere along the way.
Human beings make mistakes. You guys are giving way too much credit to the
NSA.

------
arno_u_loginlux
This just remind me of the slides from the NSA operation ORCHESTRA: Annual
Status Report in FOSDEM, Brussels, this year - see video here:
[http://t.co/8WSSjOFrLk](http://t.co/8WSSjOFrLk)

------
sdfjkl
No fix for iOS 6.x on devices capable of iOS 7 either. So now I have the
choice of no SSL or destroying my phone's UX by upgrading to iOS 7.x :-(

------
blazespin
Another explanation is that it was an act of vandalism / code graffiti by a
script kiddy or perhaps a real hacker with more skill than maturity.

~~~
MBCook
Could you explain how that's a plausible explanation? I don't see this being
the kind of thing a vandal would do.

Is external (hacker/SK) influence even possible? I know Apple releases the
source, but do they actually take patches from the community?

------
zacinbusiness
So is there evidence yet of this out in the wild? And was it discovered by
Apple or an independent researcher?

------
bwindels
And this is why you should always put curly braces around your if statement
body.

