6 ms·

Stop this nonsense. There are plainly dozens of reasons that this could have happened accidentally. Literally every single developer has made similar stupid mis

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.

pessimizer 13y ago
>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.
- matthewmacleod 13y ago
  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.
  - pessimizer 13y ago
    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
- tptacek 13y ago
  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.
  - miopa 13y ago
    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.
    - tptacek 13y ago
      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?
      - miopa 13y ago
wreegab 13y ago
> 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".
brudgers 13y ago
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-thompson.pdf http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomps...
- matthewmacleod 13y ago
  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.
  - tptacek 13y ago
    It wasn't a closed-source system. This bug was in public source code, sitting there for anyone to see it. Nobody did.
    - matthewmacleod 13y ago
      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.
      - brudgers 13y ago
        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.
luke-stanley 13y ago
That's what they expect you to think ;)

pessimizer 13y ago

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

matthewmacleod 13y ago
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.
- pessimizer 13y ago
  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
tptacek 13y ago
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.
- miopa 13y ago
  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.
  - tptacek 13y ago
    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?
    - miopa 13y ago

wreegab 13y ago

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

brudgers 13y ago

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-thompson.pdf http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomps...

matthewmacleod 13y ago
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.
- tptacek 13y ago
  It wasn't a closed-source system. This bug was in public source code, sitting there for anyone to see it. Nobody did.
  - matthewmacleod 13y ago
    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.
    - brudgers 13y ago
      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.

luke-stanley 13y ago

That's what they expect you to think ;)