3 ms·
Did you read the link? It describes an attack where you only need to have access to the same network as the target. Perhaps through that smart lightbulb they ju
by Sir_Cmpwn 10y ago
Did you read the link? It describes an attack where you only need to have access to the same network as the target. Perhaps through that smart lightbulb they just installed?
- tptacek 10y agoYes, I did read the link. Do you understand the thread? The proposal is that this bug in Kaspersky's kernel code is a backdoor in Kaspersky's kernel code --- that is: an attacker that already owns your OS kernel is backdooring it to come up with an extremely convoluted and noisy way to get access to your TLS sessions --- by backdooring the part of their kernel code that already has access to every TLS session on the machine.
- Sir_Cmpwn 10y agoThe described attack doesn't sound convoluted at all, it seems very practical.
- tptacek 10y agoOnce 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 agoI see what you mean now. If you wanted to make a backdoor and have plausable deniability, you'd make it a bug.
- tptacek 10y agoYes, 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 agoNo, 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 agoFrom 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.