3 ms·

The described attack doesn't sound convoluted at all, it seems very practical.

tptacek 10y ago
Once again: the attacker here already controls TLS on the machines that are affected. They don't need to collide certificates. By design, they not only have the plaintext of every TLS session on the machine, but they are also the client side of every TLS session originating from the machine (they terminate TLS locally and proxy it over a new connection they control). I feel like the people claiming this is a smoking gun backdoor don't really understand what it means that Kaspersky's software is designed to proxy TLS. Yes: it is batshit that they proxy TLS. It's so batshit that this particular bug makes absolutely no sense as a backdoor. That idea is Xzibit-level crazy.
- Sir_Cmpwn 10y ago
  I see what you mean now. If you wanted to make a backdoor and have plausable deniability, you'd make it a bug.
  - tptacek 10y ago
    Yes, but you would not make it this bug, which (a) doesn't get you any access you don't already have, and (b) leaves a trail of sporadically broken TLS connections so obvious that they show up in CT logs.
    - Sir_Cmpwn 10y ago
      No, you don't understand. They already had that access, but in order to exploit it they (hypothetically) need a sneaky way to do so. Hence the bug.
      - tptacek 10y ago
        From the vantage point they have now they have approximately 18 bazillion ways to generate a backdoor that yields control of the entire machine to an arbitrary person on the network. The fact that virtually every backdoor ever created works this way, and not by creating an elaborate set of circumstances through which you can get access to specific TLS sessions, is not an accident. But even in the bizarro world --- which I do not concede that we live in but will briefly stipulate to --- where you would backdoor kernel AV software that looks at TLS plaintext solely to give people the ability to get access to TLS plaintext, this still doesn't make sense. They terminate TLS locally. They are the client to every TLS session originating from the machine. They don't need to create a noisy 32 bit certificate collision, so noticeable to the Internet it shows up in CT logs, to accomplish this task. They can backdoor TLS itself in a zillion plausibly deniable ways that would give network observers access to plaintext.
        Sir_Cmpwn 10y ago
        What if they don't need control of the entire machine? Such a backdoor could be much more conspicuous. What if the NSL they were handed only called for intercepting TLS traffic as a means of surveillance?
        tptacek 10y ago
        Ironically, the backdoor that provided access to the whole machine would be far less conspicuous than this one. That's the thing about the human cognitive bias towards narratives: RCE vulnerabilities in AV are found routinely, and don't land on the top of HN. This bug did because it was so cosmically stupid, it's surprising nobody noticed it before --- something Ormandy repeatedly states in his writeup. Which is all the more reason not to believe that it's enemy action.
        Sir_Cmpwn 10y ago
        Well, I don't know much about Windows and I don't know much about the design of this software, but let's speculate some more. I imagine that on Windows, you have to have escalated permissions to modify the certificate store. I also imagine that if you were writing a piece of software that could do this (i.e. AV), you wouldn't always be running everything as root (so to speak). I would guess that most RCEs wouldn't lead to being able to modify the certifiate store.

Once again: the attacker here already controls TLS on the machines that are affected. They don't need to collide certificates. By design, they not only have the plaintext of every TLS session on the machine, but they are also the client side of every TLS session originating from the machine (they terminate TLS locally and proxy it over a new connection they control). I feel like the people claiming this is a smoking gun backdoor don't really understand what it means that Kaspersky's software is designed to proxy TLS. Yes: it is batshit that they proxy TLS. It's so batshit that this particular bug makes absolutely no sense as a backdoor. That idea is Xzibit-level crazy.

Sir_Cmpwn 10y ago
I see what you mean now. If you wanted to make a backdoor and have plausable deniability, you'd make it a bug.
- tptacek 10y ago
  Yes, but you would not make it this bug, which (a) doesn't get you any access you don't already have, and (b) leaves a trail of sporadically broken TLS connections so obvious that they show up in CT logs.
  - Sir_Cmpwn 10y ago
    No, you don't understand. They already had that access, but in order to exploit it they (hypothetically) need a sneaky way to do so. Hence the bug.
    - tptacek 10y ago
      From the vantage point they have now they have approximately 18 bazillion ways to generate a backdoor that yields control of the entire machine to an arbitrary person on the network. The fact that virtually every backdoor ever created works this way, and not by creating an elaborate set of circumstances through which you can get access to specific TLS sessions, is not an accident. But even in the bizarro world --- which I do not concede that we live in but will briefly stipulate to --- where you would backdoor kernel AV software that looks at TLS plaintext solely to give people the ability to get access to TLS plaintext, this still doesn't make sense. They terminate TLS locally. They are the client to every TLS session originating from the machine. They don't need to create a noisy 32 bit certificate collision, so noticeable to the Internet it shows up in CT logs, to accomplish this task. They can backdoor TLS itself in a zillion plausibly deniable ways that would give network observers access to plaintext.
      - Sir_Cmpwn 10y ago
        What if they don't need control of the entire machine? Such a backdoor could be much more conspicuous. What if the NSL they were handed only called for intercepting TLS traffic as a means of surveillance?
        tptacek 10y ago
        Ironically, the backdoor that provided access to the whole machine would be far less conspicuous than this one. That's the thing about the human cognitive bias towards narratives: RCE vulnerabilities in AV are found routinely, and don't land on the top of HN. This bug did because it was so cosmically stupid, it's surprising nobody noticed it before --- something Ormandy repeatedly states in his writeup. Which is all the more reason not to believe that it's enemy action.
        Sir_Cmpwn 10y ago
        Well, I don't know much about Windows and I don't know much about the design of this software, but let's speculate some more. I imagine that on Windows, you have to have escalated permissions to modify the certificate store. I also imagine that if you were writing a piece of software that could do this (i.e. AV), you wouldn't always be running everything as root (so to speak). I would guess that most RCEs wouldn't lead to being able to modify the certifiate store.