8 ms·
Besides the obvious badness of the overall system described, things like > The cache is a binary tree, and as new leaf certificates and keys are generated, the
by dom0 10y ago
Besides the obvious badness of the overall system described, things like
> The cache is a binary tree, and as new leaf certificates and keys are generated, they're inserted using the first 32 bits of MD5(serialNumber||issuer) as the key.
You know. That's not a mistake. That's what a consciously designed-in vulnerability to enable taking over the system looks like.
- jamesrom 10y agoAlmost certainly. Kaspersky are a global cybersecurity provider. There is no room for Hanlon's razor here. This was malice, not stupidity.
- tptacek 10y agoNobody who has done software security work for the security product industry agrees with you. For a variety of reasons, these products are typically several degrees worse than the median technology product.
- astrodust 10y agoA briefcase full of cash could easily get a "bug" like this introduced into a security package. I'm not saying this is the case, but given the current climate, it's hard to say it isn't.
- tptacek 10y agoYou can say that about any kind of product that everyone deploys. All software has bugs, most bugs are exploitable. So, no, it's easy to say that it isn't.
- astrodust 10y agoThis bug is so shockingly stupid you have to wonder if it's malice or staggering incompetence, so either we must admit that Kapersky has no business staying in business, or they're willing to overlook little "mistakes" like this.
- tptacek 10y agoThis is exactly what people said about the Apple "goto fail" bug. The conspiracy theories were silly then and they're silly now.
- Sir_Cmpwn 10y agoIf you are knowledgable enough to MITM SSL then you should definitely be knowledgable enough to know how stupid this is, and - frankly - knowledgable enough not to fucking MITM SSL. I would attribute it to malice, assume it's malice, fire the developer, and contact the authorities. Of course, that's moot if the authorities are the ones who asked for the bug.
- tptacek 10y agoLet's try a little exercise here. Stipulate that it's malice, and then generate the narrative in which malice makes sense. Specifically: You are whatever entity (I assume the FSB?) that can demand Kaspersky implant backdoors into its desktop antivirus software. You decide to target that backdoor at the component of Kaspersky's software that gets, by design, unrestricted access to the plaintext of all TLS sessions on the machine, in addition to practically unrestricted access to every file on machine itself, and to the machine's memory in cpl0 and cpl3. From that vantage point, you decide to... ... collide certificates? Remember, your evil backdoor only impacts machines running your software already. From this thread, I'm wondering if that's maybe unclear to people.
- Sir_Cmpwn 10y agoDid 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.
- hughw 10y agoWouldn't it be fair to say that a vulnerability in software you willingly bless to install a MITM, is worthy of more distrust (as to whether it's a deliberate vulnerability) than a similar error in an office productivity program?
- tptacek 10y agoI don't know. Aren't you asking whether I should be more worried about Microsoft Office or AV software? That's a tough choice to have to make. Productivity software file-based vulnerabilities compromise orders of magnitude more computers than MITM vulnerabilities do.
- deleted 10y ago[deleted]
- btilly 10y agoSo, no, it's easy to say that it isn't. It is easy to say whatever you want, but impossible to prove either way. Kaspersky comes from Russia, and has high level connections within the Russian government. Past actions (eg their analysis of Stuxnet) have been in line with Russian foreign policy goals. Everything that they do is easily explained by their being a normal company. But multiple things that they have done fit very well with their working for Russian policy goals in a smart way. Which theory you find more plausible depends on your level of paranoia about Russia, and how much pressure you think that Putin would bring to bear behind the scenes to force cooperation. And even if they are subject to state backdoors, any particular one might or might not be one. I personally am inclined towards paranoia. Russia using Kaspersky would be perfectly in line with standard fare in lots of countries. For example here in the USA look at how the NSA created the FREAK attack. Or look at Lenovo's use of Superfish in their BIOS. Why would we expect Russia to be more restrained than other state actors with as tempting a channel as Kaspersky? I see no reason to expect that. No reason at all.
- throwaway91111 10y agoThis is true of virtually any exploit.
- tiglionabbit 10y agoI've met plenty of programmers who are stupid enough to do this kind of thing. Don't attribute to malice what could easily be attributed to stupidity.
- wfunction 10y agoPlausible deniability?
- greglindahl 10y agoI'm not a fan of conspiracy theories, but this vuln was not patched in 90 days. Kaspersky frequently patches things faster than that, and this sure sounds like it's a pretty trivial fix.
- tptacek 10y agoIt's kernel TLS interception code. Not only is it not a trivial fix, but Tavis Ormandy had to revise his exploit model to account for functionality he hadn't noticed. It's not a conspiracy.
- xorblurb 10y agoFixing that kind of stupid hashing scheme and subsequent use of only 32 bits of the result? Might not be trivial, but, regardless of being in the kernel or not, SHOULD be easy enough to fix quickly. Even more so given how bad that hole is. So, they taking too much time to fix that? In every case one more reason to stay far far far away from their products.
- tptacek 10y agoI'm not saying you should use Kaspersky AV. Don't do that.
- jonas21 10y agoSounds like it was patched: > This issue was fixed on the 28th, there was some delay unrestricting this bug due to the holidays. And it's been less than 90 days since the issue was reported, so they wouldn't have disclosed yet if it wasn't.
- RubyPinch 10y agoIts not a mistake or a vulnerability either. Incorrect cache hits are fine, as long as there is some checking following the cache hit hash(A) == hash(B) && A == B > I wasn't aware they were checking the commonName sent with SNI. If I'm not mistaken, it does sound like they were doing some checking after they pulled the generated cert from cache, but it obviously wasn't enough checking
- kuschku 10y ago> Incorrect cache hits are fine, as long as there is some checking following the cache hit Exactly. That’s why hashmaps don’t have objects in each bucket, but an actual linked list (or partitioned linked list) with all elements hashing into that bucket. This is CS101. If you build a hashmap yourself, at least get this right.
- catfood 10y agoDoes kaspersky AV also keep a DNS cache? That would be convenient.