undefined | Better HN

0 pointslawnchair_larry7y ago0 comments

I feel like you’re telling me (and others) I’m wrong in this comment but agreeing with me in others.

As far as I can tell, the reporter made rather public denigrating statements against the authors for a total non-issue that has no attack. As in, doesn’t know what he is talking about. So I’m not sure why you want me to apologize instead of him.

You seem to be taking issue with how I worded my comment in that I made an unqualified statement about CBC IVs, which is true in applications like this, but not true broadly. Is that accurate?

The only security risk of relevance here is that if a password is reused, and any blocks are the same in multiple files, this will be evident. This is defeated so long as an IV is not reused, which can’t happen (I’m comfortable rounding “unless a user makes a 7zip archive with the same password at the exact same time on multiple machines and manages to get the same PID” down to “can’t”, to be clear) even though the IV is reasonably predictable.

In other applications, like TLS, or IPSEC, yes, the OP would have had a legit bug finding.

There is no bug here, just a bad crypto code smell. It’s like pointing to a strcpy and saying “this code has buffer overflows!” when all call sites have bounds checking or fixed size inputs.

If you think I’m still wrong about this, I’m inclined to believe you, but I think you’re only saying predictable IVs are a problem in other, unrelated applications, which I am not disagreeing with.

It’s a completely dick move even if he were correct (but he isn’t). That’s not how you report issues. The author of this (free!) software obviously isn’t a cryptographer, but he thanklessly wrote an otherwise good piece of software that millions benefit from.

If you’re going to publicly shit on his code to get points from security twitter, at least nake sure you have a real finding. But better yet, don’t be that guy.

Appsec people need to learn that they aren’t better than developers because they found the one narrow domain that they know more about than the author. It’s extremely likely that the author could teach you way more than you can teach them, so if you have a leg up somewhere, be humble about it.

Edited to add: Igor, the author, appears to be having a civil and receptive dialog with the reporter on the 7z mailing list after the fact, discussing alternatives and tradeoffs and trying to validate a potential attack. So, this isn’t even a case where someone gave a well-meaning researcher the middle finger and motivated them to go public. OP just started shitting on the guy for public praise right out of the gate (even saying he wanted to vomit over how bad this is), completely unnecessarily.

I encourage him to apologize to Igor, who sounds like he is going to fix it regardless.

0 comments

tptacek7y ago

I'm sorry. You remain wrong. Predictable IVs in CBC mode are a vulnerability. A low-severity vulnerability; so are most CSRFs. We don't generally write dozens of paragraphs about how irresponsible and clueless someone is when they report a sev:lo CSRF. In fact, what a lot of companies do for that is pay a bounty. (I know, not the fact pattern here).

You're also missing pretty much the whole conversation about why predictable IVs in ZIP's CBC is a vulnerability. Yes, as lots of people have pointed out, in the 95% use case of 7z as a simple file format, the IV doesn't matter. You can't use the flaw to decrypt someone else's 7z file.

But 7z is a file format. Applications build on top of those. Plenty of applications generate zip files. If one of them, for whatever reason, chose to generate 7z zip files with 7z's code, this sev:lo vulnerability stops being sev:lo. A predictable IV plus known prefixes turns CBC mode into ECB mode. If this person had reported 7z using ECB mode, nobody would be question the competence of the report. But they reported a more sophisticated flaw. It flies over people's heads. They claim it's bogus. You can see my issue here.

The world does not need more encouragement to write bad crypto code. We're up to our ears in it. But the world definitely needs more people to do the harder job of looking through the bad crypto and mapping out the pitfalls. Thats's what this person did. I'm fine if you don't want to thank him, I'm even fine if you just want to debate whether they reported it the best possible way (I'll disagree but we disagree on lots of things).

What I will not let anyone get away with is claiming that the finding itself is incompetent because predictable IVs are not a bug. That's not just wrong, it's theatrically wrong. I don't care if you apologize about slagging this person for reporting something. But I think you should apologize for claiming, falsely, that they were incompetent. I'm kind of a little surprised you haven't already!

j / k navigate · click thread line to collapse