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.

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.

How many angels fit on a head of a pin?

Tptacek isnt saying the issue isn't serious, it quite self evidently is, simply that other issues that appear regularly are also of equal or greater exploitability, and this being the bug that gave the NSA the keys to the kingdom is unlikely.

So what's "greater"?

Broken TLS means all my sensitive data from all my apps are exposed.

Which one is worse? With my passwords, you could access our servers, cloud storage, corporate data. You could leverage this into VPN access, and from there, easy server-side code execution.

All without ever having to actually run code on my phone and potentially trigger the notice of observant parties.

I don't know the answer so certainly as you seem to, because it seems much more complicated a question to me.

Admittedly, the above leaves aside the elephant in the room - regular old browser bugs, which are vastly more common, more likely to be reliable, and for the aforementioned other adversaries, relatively easily leveraged with exploit kits. As I assume you know, browser sandboxes provide protection against renderer bugs on MitMed or attacker-controlled origins being used to hijack a HTTPS site (and OS-level sandboxes protect non-browser SSL applications), but sandboxes get popped all the time and one of the two targets of this bug, iOS Safari, is single-process, so meh.

I agree the coverage of this bug is overblown (...depressingly, since that's just saying that modern computing is drastically insecure); I strongly doubt it was introduced intentionally, or that the NSA, if it knew about it, was "relying on" it in the sense that the disclosure is a huge loss. But it's still a particularly good bug.

Actually... yes. Memory corruption bugs are harder to exploit quietly, because if you get something wrong you'll get a crash instead of code execution. Missing certificate validation is much safer to exploit.

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.

Some organizations--and even though it's easy to mock Apple here, I do believe they're one of them--sufficiently appreciate that improving security minimizes risk, and so spend a decent amount of money on it. You could argue they failed here, but even Adam Langley who essentially "is SSL" at Google admits he's not sure they have a test that simulates an attack on a possible similar implementation error in their own code (though he does argue that such an error would have been caught in Google's code review process.)

In any case, an attention to security is certainly not something that is borne out of an organization's revenue or number of employees.

I can totally see this being "innocent 2AM mis-judgement call by a single employee", judging from what my peers tell me of Apple's corporate culture. I do think that Adam Langley's suggestion that code review would help is plausible, but it merely just means that more than one person has to make the same mistake in a judgement call. (It reduces the probability of such an error happening; it doesn't theoretically eliminate it.)

https://support.apple.com/library/APPLE/APPLECARE_ALLGEOS/HT...

We begin therefore where they are determined not to end, with the question whether any form of democratic self-government, anywhere, is consistent with the kind of massive, pervasive, surveillance into which the Unites Sta tes government has led not only us but the world.

This should not actually be a complicated inquiry.

http://snowdenandthefuture.info/events.html

Take, for example, the implementation Dual EC DRBG in the FIPS 140-2 certified OpenSSL module -- it was fatally flawed, and has never worked in practice. (It will be removed from the next version of the module in light of developments in the past year.)

https://lwn.net/Articles/578375/

Exactly. That sums up my feelings about it better than I could. Something so critical, something trivially easy to catch in a code review was not caught. And, the only scenario in which a code review might not have caught it: no code review. That's no code review for libssl.

If this is incompetence and not malice, it's incompetence of monumental proportions.

Code reviews only mean your code is going through two sieves instead of one.

Of course it helps. But there is no guarantee of anything unless the reviewer is incapable of making mistakes, in which case you could just ask him to write the code in the first place.

Did you look at the bug? I'll quote it here:

    if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)  
        goto fail;
    if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)    
        goto fail;  
        goto fail;  
    if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)  
        goto fail;  

        if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)  
            goto fail;
        if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)    
            goto fail;
    -   if ((err = SSLHashSHA1.update(&hashCtx, &somethingElse)) != 0)
            goto fail;  
        if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)  
            goto fail;

    if ((err = ReadyHash(&SSLHashSHA1, &hashCtx, ctx)) != 0)
        goto fail;

    if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0)
        goto fail;

Diff35

  if (...) {
    goto fail;
  }
  if (...) {
    goto fail;
    goto fail;
  }
  if (...) {
    goto fail;
  }

  if (...) {
    goto fail;
  }
  if (...) {
    goto fail;
  }
    goto fail;
  if (...) {
    goto fail;
  }

I disagree. We are human. We are not divine. We do stupid things and we can write stupid infinite loop or off-by-1 and the bug will live for a decade. I am sure you have written a program which can be easily exploited and you know that it is such a trivial bug.

There are many many ways this should have been caught before it even left the building by numerous automated tools. Heck most modern IDEs will flag unreachable code in the editor so there is no real excuse for this. (Adding -Wunreachable-code to a sample project in Xcode immediately flags the next line).

The programmer is human which is why automated verification tools exist.

(AppCode's default inspections will also flag the issue providing you run them)

I am not familiar with running static analysis and looking output, only did very minimal undefined behavior santisizer detection.

Lax development is par for the course at these mega corps.

For example, according to the Wayback Machine, our sites page had an entry about it since 2009:

http://web.archive.org/web/20091123132855/http://www.chromiu...

http://www.reddit.com/r/programming/comments/mw2sn/googles_a...

You take the experienced people off the shop floor, and call them inspectors. So now the quality of product coming off the shop floor is worse.

Ann is the first inspector in the chain. When she's busy (and remember, she will be because quality has dropped) she might be tempted to let a few things go because Bob, the second inspector in the chain, is bound to catch them. That's what he's there for.

Bob is the second inspector in the chain. Sometimes Ann really churns the product through. Luckily during those busy times he knows she's already inspected the stuff, so he only needs to give a 10% inspection.

So you have worse product with more errors and leaky inspection.

Ideally you'd have a system with skilled workers and self inspection. That's okay for aerospace (which pays well) but not so great for lower cost product.

Not quite sure how this transfers to coding.

How about this:

owner/peer of the module has to sign off, and randomly select two more. One must be QA and one is another programmer who works on the module. We can also pick a "junior" level, but then that's probably not going to work since Apple employes programmers who have some years of experience already. Or we can pick someone who isn't directly working on that module, but have some qualification to do review. Mostly just asking "why are you having two goto, why return -100 here)

But I see counterargument: they will just listen to the author if he's senior or the owner who is also a senior. Their words carry weight.

This is why it's a big deal.

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

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)

One of the sources: http://www.forbes.com/sites/erikkain/2013/12/30/the-nsa-repo...

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

Suppose a contractor was hired by the NSA to write an exploit with equivalent function. How could it be crafted more cleverly?

Apple's TLS handshake bug was trivially easy to exploit, entirely silently, in a fully automated fashion and with zero chance of detection and without leaving a trace. That's why it's a big deal.

If you are in the business of collecting massive amounts of data, this is exactly the type of bug that you would be using. SSL clients leak a large amount of data in the handshake (supported protocol versions, cipher suites, extensions, etc), allowing you to fingerprint them and detect the vulnerable ones on per connection basis. You then attack, safe in knowing that you won't be detected.

Once you get the victim's password (e.g., if you attack their email client), you can suck out all the data you want. Because you are the MITM, you can do it from their own IP address, too. All fully automated.

I think we can all agree that owning the entire platform on a device is far worse than a MITM attack on a session. Even if it's all the sessions on that platform using TLS/SSL. executing code on the box means you can do many other things on that box, such as setting up a pivot point and keeping access to the platform as long as you want. If you can root the platform, then all bets are off.

If you don't have authenticity, the "secure" channel isn't worth very much.

I'm not sure why this is being classed differently.

Since then, we've learned that FAA 702 orders add up to a tiny fraction of user accounts. The order of magnitude is 1,000 accounts per company per year. I really can't get too worked up about this; there are bad guys out there and that figure seems not immediately unreasonable. What we should get worked up about is bulk AT&T etc. fiber taps that vacuum up everything without any accountability, but, well, PRISM is a nice sexy name and everyone's attention spans are short and, yikes, isn't this confusing and BULLRUN and EDGEHILL are too hard to remember. Right?

No companies "joined" PRISM. The slides are likely referring to when NSA managed to write the conversion utilities to import FAA 702-obtained records into the PRISM database. But critical thinking is hard and life is short. Right?

Man in the middle attack does not require code execution because the data is already available.

In a sense, this bug is like having part of a keyboard sniffer already installed for you.

It probably wasn't the only trick in their book, but it was surely one of them (and a quite useful one at that).

To me, the interesting question brought up by this story is how soon the vulnerability was known to potential exploiters. Did they just have to have an appropriate set of black box tests rigorously applied to every major software release to spot this? That would, sadly, diminish my trust in the quality of Apple's engineering, though I don't see a reason to attribute it to an inside job without any evidence.

What I'm afraid of is an attacker stealing my credentials. Code execution bugs obviously is game over for me. But now with everything in the cloud, an attacker could get all I'm afraid of losing by fucking with my SSL connections. If they get access to everything I have on the web the fact that my machine executed no malicious code locally is no consolation.

Kind of makes me want to investigate what work you and your company has done for the NSA.

Nice ad hominem, dude.