16 ms·

On the Timing of iOS’s SSL Vulnerability and Apple’s ‘Addition’ to NSA’s PRISM

257 points by dieulot 13y ago

sdfjkl 13y ago
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 :-(
tptacek 13y ago
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.
- aidos 13y ago
  Obviously, I trust you to know about these things, and you point to other bad examples which I'm not familiar with. In this context though, code execution isn't necessarily important (though I'm sure that's a dream scenario). The ability to snoop on assumed secure traffic is a pretty sweet starting point.
- briansmith 13y ago
  > (it's the TLS library for Firefox and Chrome) The False Start bug in NSS that you are talking about (CVE-2013-1740) never affected a released version of Firefox; we found the bug during testing of False Start in preparation for enabling it in Firefox 26. We pushed back the enabling of False Start to Firefox 28 (which will be released next month) so that we could fix this bug first.
- thirsteh 13y ago
  You seem to be downplaying the seriousness of the bug to the point of making it seem trivial, and while I agree that there are many, much more serious types of bugs that 1. don't require active MITM, and 2. the press don't give proportionate attention, it is only "trivial" in the same way that Yahoo not using SSL for their webmail is "trivial," or the way a website leaking an authentication cookie over HTTP is. Only here it's not just Yahoo's email; it's (almost) all applications. (Not to mention that you can use these "secure" channels to deliver e.g. memory corruption exploits.) If you don't have authenticity, the "secure" channel isn't worth very much.
- teacup50 13y ago
  You have an odd definition of "less exploitable". On what planet is compromise of all trusted communications "less exploitable" just because it doesn't immediately lead to code execution? Once you are MITM'ing, you get passwords. You get personal details. You get everything you need to do far, far more than run code on someone's phone. All the vulnerabilities you list are bad. Sometimes I wonder if you post your consistently contrarian posts on HN just to stay visible.
  - throwaway2048 13y ago
gojomo 13y ago
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?
- 0x0 13y ago
  Good points. Could it simply be that someone working on this code at apple have had their computer backdoored, and the attacker snuck in the double goto in their working source dir, just waiting for it to be picked up on the next commit? I remember reading an article some time ago how facebook played out this exact scenario, even going to such lengths as acquiring a 0day to keep the simulation even more real.
- judk 13y ago
  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...
aidos 13y ago
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 13y ago
  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.)
prehkugler 13y ago
> 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/libsecurity_ssl/lib/sslKeyExchange.c http://opensource.apple.com/source/Security/Security-55471/l...). 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 13y ago
  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 13y ago
    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
higherpurpose 13y ago
> 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 13y ago
  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/
sneak 13y ago
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 13y ago
  We are definitely using the term PRISM that way.
  - vilhelm_s 13y ago
    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.
blazespin 13y ago
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 13y ago
  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?
0x0 13y ago
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.
- thrownaway2424 13y ago
  Where's the commit that introduced the extra goto? I haven't seen it yet.
  - 0x0 13y ago
    As outsiders we can't see commits, but the next best thing is a diff between the public source code releases: https://gist.github.com/alexyakoubian/9151610/revisions https://gist.github.com/alexyakoubian/9151610/revisions
    - thirsteh 13y ago
      Line 631 in the second column for anyone wondering.
    - MBCook 13y ago
      It could have been merge between public releases. My money would be on a copy & paste error, but there is no more evidence for that than the merge error theory.
    - thrownaway2424 13y ago
      Pretty yak-shavy. Looks like some symbols were renamed and many of the APIs were (probably pointlessly) mutated. In total, unreviewable. But as you say, this may not have been the internal diff seen by someone at Apple. They may have seen individual, focussed patches that did single things like changing from the 2-argument to the 1-argument SSLFreeBuffer, another patch for changing selectedCipherSpec to selectedCipherSpecParams (hello, yak shaving), renaming noErr to errSecSuccess, and so forth. The question is, in any of those changes, the extra "goto fail;" line would have stuck out as irrelevant. In a gigantic 500-line delta the reviewer's eyes may have been glazed over by the time they got to that one. Assuming anyone reviews code at Apple, of course.
deleted 13y ago
[deleted]
terminus 13y ago
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 13y ago
  "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 13y ago
    > 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.
yeukhon 13y ago
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.
tyho 13y ago
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?
rrggrr 13y ago
Where is the patch for OSX Mavericks Apple? Patches aplenty for iOS yet it appears Safari is still vulnerable.
- panacea 13y ago
  Deafening silence.
- d0 13y ago
  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.
cdoxsey 13y ago
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"
codezero 13y ago
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...
zacinbusiness 13y ago
So is there evidence yet of this out in the wild? And was it discovered by Apple or an independent researcher?
daniel-cussen 13y ago
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.
- nicky0 13y ago
  Jobs died in October 2011
- lern_too_spel 13y ago
  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.
deleted 13y ago
[deleted]
arno_u_loginlux 13y ago
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
silvestrov 13y ago
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 13y ago
  The "person" who made the "error" in the core code could have made a similar "error" in the unit test.
  - PhantomGremlin 13y ago
    Yes, that would be quite the "coincidence", wouldn't it?
bandushrew 13y ago
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.
higherpurpose 13y ago
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 13y ago
  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.
blago 13y ago
“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.
bwindels 13y ago
And this is why you should always put curly braces around your if statement body.
yarou 13y ago
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.
bsder 13y ago
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.

257 points by dieulot 13y ago

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 :-(

tptacek 13y ago

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.

aidos 13y ago
Obviously, I trust you to know about these things, and you point to other bad examples which I'm not familiar with. In this context though, code execution isn't necessarily important (though I'm sure that's a dream scenario). The ability to snoop on assumed secure traffic is a pretty sweet starting point.
briansmith 13y ago
> (it's the TLS library for Firefox and Chrome) The False Start bug in NSS that you are talking about (CVE-2013-1740) never affected a released version of Firefox; we found the bug during testing of False Start in preparation for enabling it in Firefox 26. We pushed back the enabling of False Start to Firefox 28 (which will be released next month) so that we could fix this bug first.
thirsteh 13y ago
You seem to be downplaying the seriousness of the bug to the point of making it seem trivial, and while I agree that there are many, much more serious types of bugs that 1. don't require active MITM, and 2. the press don't give proportionate attention, it is only "trivial" in the same way that Yahoo not using SSL for their webmail is "trivial," or the way a website leaking an authentication cookie over HTTP is. Only here it's not just Yahoo's email; it's (almost) all applications. (Not to mention that you can use these "secure" channels to deliver e.g. memory corruption exploits.) If you don't have authenticity, the "secure" channel isn't worth very much.
teacup50 13y ago
You have an odd definition of "less exploitable". On what planet is compromise of all trusted communications "less exploitable" just because it doesn't immediately lead to code execution? Once you are MITM'ing, you get passwords. You get personal details. You get everything you need to do far, far more than run code on someone's phone. All the vulnerabilities you list are bad. Sometimes I wonder if you post your consistently contrarian posts on HN just to stay visible.
- throwaway2048 13y ago

gojomo 13y ago

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?

0x0 13y ago
Good points. Could it simply be that someone working on this code at apple have had their computer backdoored, and the attacker snuck in the double goto in their working source dir, just waiting for it to be picked up on the next commit? I remember reading an article some time ago how facebook played out this exact scenario, even going to such lengths as acquiring a 0day to keep the simulation even more real.
judk 13y ago
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...

aidos 13y ago

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 13y ago
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.)

prehkugler 13y ago

> 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/libsecurity_ssl/lib/sslKeyExchange.c http://opensource.apple.com/source/Security/Security-55471/l...). 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 13y ago
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 13y ago
  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

higherpurpose 13y ago

> 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 13y ago
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/

sneak 13y ago

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 13y ago
We are definitely using the term PRISM that way.
- vilhelm_s 13y ago
  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.

blazespin 13y ago

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 13y ago
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?

0x0 13y ago

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.

thrownaway2424 13y ago
Where's the commit that introduced the extra goto? I haven't seen it yet.
- 0x0 13y ago
  As outsiders we can't see commits, but the next best thing is a diff between the public source code releases: https://gist.github.com/alexyakoubian/9151610/revisions https://gist.github.com/alexyakoubian/9151610/revisions
  - thirsteh 13y ago
    Line 631 in the second column for anyone wondering.
  - MBCook 13y ago
    It could have been merge between public releases. My money would be on a copy & paste error, but there is no more evidence for that than the merge error theory.
  - thrownaway2424 13y ago
    Pretty yak-shavy. Looks like some symbols were renamed and many of the APIs were (probably pointlessly) mutated. In total, unreviewable. But as you say, this may not have been the internal diff seen by someone at Apple. They may have seen individual, focussed patches that did single things like changing from the 2-argument to the 1-argument SSLFreeBuffer, another patch for changing selectedCipherSpec to selectedCipherSpecParams (hello, yak shaving), renaming noErr to errSecSuccess, and so forth. The question is, in any of those changes, the extra "goto fail;" line would have stuck out as irrelevant. In a gigantic 500-line delta the reviewer's eyes may have been glazed over by the time they got to that one. Assuming anyone reviews code at Apple, of course.

deleted 13y ago

[deleted]

terminus 13y ago

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 13y ago
"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 13y ago
  > 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.

yeukhon 13y ago

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.

tyho 13y ago

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?

rrggrr 13y ago

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

panacea 13y ago
Deafening silence.
d0 13y ago
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.

cdoxsey 13y ago

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"

codezero 13y ago

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

zacinbusiness 13y ago

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

daniel-cussen 13y ago

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.

nicky0 13y ago
Jobs died in October 2011
lern_too_spel 13y ago
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.

deleted 13y ago

[deleted]

arno_u_loginlux 13y ago

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

silvestrov 13y ago

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 13y ago
The "person" who made the "error" in the core code could have made a similar "error" in the unit test.
- PhantomGremlin 13y ago
  Yes, that would be quite the "coincidence", wouldn't it?

bandushrew 13y ago

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.

higherpurpose 13y ago

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 13y ago
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.

blago 13y ago

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

bwindels 13y ago

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

yarou 13y ago

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.

bsder 13y ago

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.