Hacker News Reader

Comment by matthewmacleod | Hacker News Reader

Stop this nonsense. There are plainly dozens of reasons that this could have happened accidentally. Literally every single developer has made similar stupid mistake, and literally every organisation has released stupidly broken code.

Yes, there should have been code review, static analysis, and testing in place to prevent that. That'll probably start happening, and you can bet that there will be serious discussions internally about what happened.

If this was the action of a malicious government agency, then it was horribly hamfisted execution. It might offer plausible deniability in some sense, but it's hard to imagine a situation where such an action would be worthwhile, given the resources at the disposal of any such actor.

View on HN

>it's hard to imagine a situation where such an action would be worthwhile, given the resources at the disposal of any such actor.

This needs more defense. I find it hard to imagine a situation where such a minimal and deniable action with such a massive effect wouldn't be worthwhile.

This needs more defense. I find it hard to imagine a situation where such a minimal and deniable action with such a massive effect wouldn't be worthwhile.

Because the goal of any such agency is not "let's render a minority of computing devices insecure for a short period under certain circumstances." That entire argument hinges on the idea that taking this action would have achieved some kind of desirable goal, when it simply would not have.

In fact, the whole thing is a massive distraction. There are myriad easier ways to conduct individual surveillance if that was the goal, and I would be much more concerned about the fact that these same agents already apparently have legal carte blanche to intercept traffic in other ways.

Thanks.

I think that your defense hinges on this being the only thing that they are doing. As one of many things, with no risk and little expended effort, why not?

>There are myriad easier ways to conduct individual surveillance if that was the goal

What's easier than getting a call from somebody placed at a tech company indicating that one of the most security critical pieces of code didn't have test coverage and wasn't statically analyzed before going into the build has a spot where an errant line could be inserted, in a way that could be argued later was accidental.

The total marginal cost to that hypothetical situation would have been to say 'ok.'

>these same agents already apparently have legal carte blanche to intercept traffic in other ways.

intercepting traffic != decoding traffic

No, it doesn't need a defense. There is no evidence to back up the idea that the bug was malicious. People that have worked on large C codebases have seen crazier things than this. Routinely.

I understand that Rails developers believe that all the TLS stacks must have dense rspec test coverage and zero-warnings static analysis passes in their builds, but that isn't the reality for any TLS stack. These aren't Rails apps (and, hate to break it to some of you, but your Rails test coverage isn't doing as much for your security as you'd like to think it is).

This is a nutball conspiracy theory, another example of the tech "community" eating its own rather than focusing on anything that would help mitigate state-sponsored surveillance. And it's happening solely in the service of an "exciting" narrative. The people promoting this bullshit conspiracy theory are, by and large, doing it because they want it to be true.

1. It is certain that NSA has some very smart people playing with the sources of the Apple crypto-modules.

2. If you're a NSA boss, and some of your experts told you that you can break SSL in Apple products with adding one line that could be almost certainly attributed to inconspicuous human error, would you try to make a deal with Apple?

3. If you're an Apple boss, and NSA offers you cache (or other benefits, like competitor intelligence) for adding plausibly deniable bug in your code, would you turn it down?

There is no direct evidence for this case, sure. There is however ample evidence in the Snowden docs that this scenario happens too often for this to be called bullshit conspiracy theory.

None of this is evidence. This is all innuendo. I could apply the exact same set of arguments to the Rails YAML bug, or to whatever the last Chrome bug Pinkie Pie got working was.

Nobody doubts your ability to spin some coherent-sounding story about the TLS bug. It's not a hard game to play. People have been playing it for centuries. How about you try a more fun topic, like alien landings?

You should make a difference between plausible conspiracy theory and bullshit conspiracy theory. Conspiracies happen quite often, having no evidence just makes them higher quality.

Remember how Diaspora was supposed to be the private peer-to-peer encrypted Facebook but peers private keys could be read or overwritten by anyone on the Internet? Doesn't your argument suggest "Well we can't rule out the NSA having a man on the inside trying to undermine their encryption"? Heck, why not go all the way: the NSA funded Diaspora to bring Facebook to the negotiating table?

Down this path lies madness. Software has bugs.

Yes, we can't rule that. But we could clearly see that the Diaspora codebase screamed incompetence. Apple, on the other hand, has some very high quality products and decades of experience.

Yes, it is quite possible that this is a simple bug. The other option is also quite possible :)

It is equally possible that Apple is a giant conspiracy dedicated to concealing the grey aliens who actually control human civilization and are harvesting our brainwaves, which actually function as the raw compute for a giant intergalactic payments call center application, via Flappy Bird. Think about it.

That's not equally possible, due to Occam's razor: http://en.wikipedia.org/wiki/Occam's_razor Plus, the security services have a proven ability and intent. Be serious now.

People seem to forget that NSA is not the only player in town. When you plant weaknesses into things, you need to make sure that you're not actually helping your adversaries. You need to carefully weigh the chance/cost of discovery by an adversary against what you get out of the weakness. The perfect case is when you're guaranteed to own the weakness, ala Dual_EC_DRBG.

Consider that the NSA has already been known to burn stolen certificates for malware code signing. It's therefore not a stretch to assume they can easily MITM TLS without needing the help from bugs.

If they planted this bug, they would have been effectively democratizing TLS MITM to virtually everyone. This would help their adversaries more than it would help them, so I'm not convinced. It's easier for me to buy that the Chrome Pinkie Pie bugs were planted, due to the hardness of their discovery, than this could ever be.

> If you're an Apple boss, and NSA offers you cache (or other benefits, like competitor intelligence) for adding plausibly deniable bug in your code, would you turn it down?

With other companies, I might find this plausible, but I do not believe Apple is very hard-up for cash or direction on which way the market is going. It seems to me that they have more to lose from a high-profile security breach (say, if this vulnerability had been used in a mass theft) than they do to gain from anything the NSA could offer them.

>it's hard to imagine a situation where such an action would be worthwhile, given the resources at the disposal of any such actor.

This needs a defense.

>There is no evidence to back up the idea that the bug was malicious.

This is completely unrelated to what I said needs a defense. It's like you weren't even responding to me.

edit: I don't know Rails.

As if read from a script, the discussion now flees to abstraction and hypothetical. I'm not interested.

I don't know what you're talking about, or what you're responding to that I've said, so your lack of interest is not hurting my feelings.

The oddest thing about it is that people who ought to know better are not straight up calling it the tinfoilhattery that it is. Schneier saying things like 'if I were doing this deliberately, that's how I'd do it'. That's how you'd do it and then you'd release the source? Why not patch the binary? Hell, why not patch the compiler, Ken Thompson-style, if you're such a devious insider? It's grade-A Chewbacca defense.

How should a malicious actor have better crafted an exploit of equivalent scope and potency?

Considering the possibility that any system managed from a compromised device could be compromised to any degree, how does the use of static code analysis and testing in the future uncompromise those systems?

Short of finding a unicorn and seeing who can ride it, there's no guarantee that a system isn't pwnd or connected to one that's pwnd. The certificate failure means binaries could have been pushed.

The problem is that you can't trust trust.

http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomps...

It doesn't. But since you were relying on a closed-source system in the first place, you are already screwed - if that's the level of security you require.

It wasn't a closed-source system. This bug was in public source code, sitting there for anyone to see it. Nobody did.

I'm aware that this particular code was - but presumably whichever hypothetical person has arbitrary binaries pushed to them in the grandparent's scenario was using a Mac or iOS.

Server A is trusted by server B. Danny uses his iPhone to manage server A - ie he accesses server A in a privileged state from his iPhone. If we treat his iPhone as compromised, then the rest of the chain of trust should be treated as comprised all the way through server B.

And that's the more difficult exploit to engineer. If Danny is using OSX for administration and we treat his installation as compromised we get a much richer stack for exploiting server A.

If Apple isn't dogfooding Macs in its development stack, I'd be surprised. Honest mistake theories drawing upon the mechanisms of Xcode fall away. So, yes, in the big picture Apple is fucked so far as security goes. Short of a source code audit- and from whence come auditors of divine perfection- trust consists of no more than wishful thoughts that the breach was an honest error that went unnoticed by everyone who might have wished to exploit it.

Have you ever looked through the code in OpenSSL?

Whenever someone brings up the "trusting trust" thingy, I feel compelled to point out the antidote: http://www.dwheeler.com/trusting-trust/

> If this was the action of a malicious government agency, then it was horribly hamfisted execution

If this was the action of a malicious government agency, you're the proof it was an awesome move, given your "Stop this nonsense".

That's what they expect you to think ;)

Reply on news.ycombinator.com