Why was "goto fail;" added without any other change to that part of the code? • Hacker News Board

Re: Why was "goto fail;" added without any other change to that part of the code?

#61

Post by tptacek » Fri, Feb 28, 2014, 5:11 PM UTC

miopa wrote: post #60

tptacek wrote: post #41

Earlier quoted context omitted.

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 a…

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 c…

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?

Re: Why was "goto fail;" added without any other change to that part of the code?

#62

Post by ryandrake » Fri, Feb 28, 2014, 5:14 PM UTC

dllthomas wrote: post #46

laureny wrote: post #21

Earlier quoted context omitted.

TDD might be useful for unit tests (even that I'm not convinced of) but not for integration tests. The bug happens very deep inside the handshake protocol and it's extremely hard to test it automatically.

Right, this is a much stronger case for static analysis and warning-free builds. This change caused dead code. If that code was supposed to be dead, comment it out.

If the code is supposed to be dead, DELETE it. Do not comment it out.

If the code doesn't belong there, get rid of it. If, for whatever reason, you want to show the reader that code used to be there, delete it and leave an explanatory comment. If you're commenting it out because you're not confident in taking it out or you plan to re-enable it in the future, well, that's what you have source control for.

Re: Why was "goto fail;" added without any other change to that part of the code?

#63

Post by pessimizer » Fri, Feb 28, 2014, 5:20 PM UTC

tptacek wrote: post #41

pessimizer wrote: post #30

Earlier quoted context omitted.

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

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 a…

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

Re: Why was "goto fail;" added without any other change to that part of the code?

#64

Post by miopa » Fri, Feb 28, 2014, 5:20 PM UTC

tptacek wrote: post #61

miopa wrote: post #60

Earlier quoted context omitted.

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 c…

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.

Re: Why was "goto fail;" added without any other change to that part of the code?

#65

Post by brudgers » Fri, Feb 28, 2014, 5:21 PM UTC

matthewmacleod wrote: post #56

brudgers wrote: post #54

Earlier quoted context omitted.

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 o…

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

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.

Re: Why was "goto fail;" added without any other change to that part of the code?

#66

Post by patio11 » Fri, Feb 28, 2014, 5:22 PM UTC

miopa wrote: post #60

tptacek wrote: post #41

Earlier quoted context omitted.

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 a…

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 c…

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.

Re: Why was "goto fail;" added without any other change to that part of the code?

#67

Post by dllthomas » Fri, Feb 28, 2014, 5:24 PM UTC

ryandrake wrote: post #62

dllthomas wrote: post #46

Earlier quoted context omitted.

Right, this is a much stronger case for static analysis and warning-free builds. This change caused dead code. If that code was supposed to be dead, comment it out.

If the code is supposed to be dead, DELETE it. Do not comment it out. If the code doesn't belong there, get rid of it. If, for whatever reason, you want to show the reader that code used to be there, delete it and leave an explanatory comment. If you're commenting it out because you're not confident in taking it out or you plan to re-enable it in the future, well, that's what you have source control for.

I don't agree. Or I do to a point, but it's a relatively weak point. I agree code should be yanked if there's no reason to be keeping it around. I don't think there's never reason to be keeping it around. Sending people to figure out which version of the repository had the relevant piece of code (which is now correspondingly less likely to have been updated at all when surrounding code changed) doesn't make sense if you genuinely expect it will be relevant again soon.

Re: Why was "goto fail;" added without any other change to that part of the code?

#68

Post by miopa » Fri, Feb 28, 2014, 5:32 PM UTC

patio11 wrote: post #66

miopa wrote: post #60

Earlier quoted context omitted.

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 c…

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

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

Re: Why was "goto fail;" added without any other change to that part of the code?

#69

Post by tptacek » Fri, Feb 28, 2014, 5:33 PM UTC

pessimizer wrote: post #63

tptacek wrote: post #41

Earlier quoted context omitted.

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 a…

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

Re: Why was "goto fail;" added without any other change to that part of the code?

#70

Post by brudgers » Fri, Feb 28, 2014, 5:36 PM UTC

matthewmacleod wrote: post #59

tptacek wrote: post #58

Earlier quoted context omitted.

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.