7-zip broken password random number generator(threadreaderapp.com) |
7-zip broken password random number generator(threadreaderapp.com) |
The flaw they're pointing out is that 7z's AES encryptor has a 64-bit IV (half the block size) --- not itself a vulnerability in block ciphers --- and uses a predictable RNG to generate the IV (for simplicity, just call it "time and pid"). 7z uses AES in CBC mode.
In CBC, you want IVs to be unpredictable; if you can predict an IV and you control some of the plaintext, you can in some cases make predictions about secret data that follows your controlled plaintext (this is an "adaptive chosen plaintext" attack).
This doesn't really come up in 7z's usage model; you're supposing someone integrates 7z with their own application, which, on-demand, encrypts attacker-controlled data with a secret suffix and puts it somewhere the same attacker can see the resulting ciphertext. Don't do this. In fact, if you're using ZIP archives in your application, don't use ZIP's AES at all; encrypt yourself with a modern mode. ZIP AES isn't meaningfully authenticated.
Having said all that: for the normal usage of an encrypted ZIP, this doesn't really matter at all.
It's a good finding, though! Cheers to anyone who takes the time to look at the underlying code for any popular cryptography. I hope they keep it up.
A more important PSA: unless you're absolutely sure otherwise, you should always assume any ZIP program you're using doesn't actually encrypt password-protected ZIPs. It's just as likely that it's using the old, broken PKWARE cipher, which is dispiritingly common due to backwards-compat concerns. It would be nice if there was a mainstream, built-in way to password-protect a file that you could share with someone else (or just stick on a thumb drive), but ZIP encryption isn't it.
Pentesters sometimes go out of their way to use 7z because it actually does encrypt with a real cipher. And, I guess for what we're doing with it, 7z is fine. But it's sad that it's the best common denominator we have.
This is going to sound really ghetto, but if you zip up some files, drag and drop the zip archive into a (modern) Word document, then pick File->Info->Protect Document->Encrypt With Password, you end up with a shareable file with decent encryption. IIRC, key generation is done with 500,000 rounds of SHA512 (which takes about 0.8 seconds on a contemporary CPU) and the encryption is 256-bit AES.
It sounds like you are conflating the zip file format with the 7z file format (both of which can be created by 7zip, the program). The plaintext attack discussed in the tweets was for zip files created by 7zip, while most of the blog post was about 7z files. (Edit: are you suggesting that there is the same security issue in both? Because that was unclear from both your comment and the blog post, given that neither explicitly says so but, presumably, 7z format and zip format are quite different).
I think a lot of techies (I really mean "me") would already suspect that zip format could be problematic, even with AES encryption. But the same techies (me again) would reasonably expect 7z with AES to be safe so long as you have a sufficiently strong password, since it was created a lot later than zip with encryption designed in from the start. I still don't really understand if the issue in the blog post is really a problem for me (sharing files through one channel while sending passwords through another channel).
Often the password comes in the same mail or website, after all.
Well, it's a "real" cipher, but with a legacy, unauthenticated cipher mode. This means basically as soon as you encrypt any active content you can have an attack similar to efail.
(My confidence here is high but not absolute).
so 7zip AES is not actually AES? Obviously the source code shows it is
Essentially, if you take an arbitrary “zip” implementation that offers password protection there are reasonably good odds that it isn’t using the “modern” aes based mechanism.
A predictable IV is only really useful if you can induce a target to repeatedly encrypt content using the same secret key, then an attacker can use known source content for some outputs to break the encryption for the unknown cases.
But again this requires a service that isn’t likely to really exist.
Just because a bunch of tinfoils are arguing over whatever doesn't mean you shouldn't still report it! Just be sure to word the report more generic than usual so the hordes don't find the issue and turn it into a battleground before a serious maintainer can get to it
The twitter thread that this is aggregated from has replies that seem to indicate that there is no practical exploit here.
https://github.com/jedisct1/libsodium/blob/master/src/libsod...
They sum it up in their docs like this:
- On Windows systems, the RtlGenRandom() function is used
- On OpenBSD and Bitrig, the arc4random() function is used
- On recent Linux kernels, the getrandom system call is used
- On other Unices, the /dev/urandom device is used
And 7-Zip first shipped in 1999. Granted, AES support was only added in 2003, but the app still had to run on Win2K and 9x back then.
Guys, this is not how info security should be taken. Just follow best practices, and experts recommendations, even when you cannot immediately see how it can be exploited. Because tomorrow someone _may_ actually find an exploit there. Finding exploits is a hard job, and a bit of luck.
so that routine... while far from ideal would seem to mostly satisfy that property if you are making zip files of your own data to send to people (unless you use the same key rather a lot)
Random IVs in CBC mode are an easy way to be fairly sure that you wont accidentally repeat a key+IV without much effort, but there is no security dependency on it being random nor on it being secret.
1) You encrypt two pieces of data within the same second in the same process (so probably using the library?)
2) or if you're using the command-line, the attack is you encrypt two pieces of data within the same second, and somehow wrap-around your pid within the second to get the same pid again.
That may be enough, or not enough -- but for those that claim that's not enough, one needs to recognize the cognitive dissonance with reusing the same password
A monotonically increasing integer as IV is perfectly fine, and this dude is a bit out of his depth thinking IVs need to be random.
Someone should make a bug bounty for all the major encryption programs, 7zp, wnzip, etc. Allocate 5 or so encrypted bitcoin private keys (with brute-force resistant passwords) for each program and see how long it lasts, with he public keys made public so people verify the status. if zip's bounty has lasted years, then it's reasonable to assume it's safe.
Nobody claims this. Open source code is just easier to audit than non-open code.
0: In the same sense that the hash of a arbitrary string is guaranteed to not be all-bits-zero or that a fair coin is guaranteed not to come up heads 100 times in a row.
When is the insufferably arrogant techno mage trope going to die?
Probably at the same time as insufferably bad software engineering dies
https://stackoverflow.com/questions/3008139/why-is-using-a-n...
Therefore in a strict sense, this is "broken". However, the "I zipped a file and it to someone" scenario is not one in which the above attack is practical.
https://stackoverflow.com/questions/3225640/how-to-decrypt-a...
the odds of the 7zip generator choosing an IV that corresponds to a re-USED IV for the same first block for a different message are very small and one would need to have access to this message
As to the core of your argument, I think your position is too extreme. It depends very much if the software was developed using formal methods and a specialized language. Safety-critical systems are rarely open source, and yet a lot of effort and resources is put to make them secure. That other project choose time-to-market rather than security is their choice, not something inherent to open or closed-source software.
# if defined(__FreeBSD_version) && __FreeBSD_version >= 1200000
# include <sys/random.h>
# define HAVE_LINUX_COMPATIBLE_GETRANDOM* Rogaway's IPSEC chained CBC IV attack
* Bard's HTTPS predictable CBC IV attack
* Dai's attack on SSH
* Thai Duong and Juliano Rizzo's BEAST
... all of which are based on predictable IVs (usually: the last block of the previous message, which is taken as a synthetic IV in 1990s-era protocols). In short: no, CBC IVs must be unpredictable.
Edit: Sounds like you addressed this in your other comment. So again, there is no attack here and OP doesn’t know what he is talking about...right?
('garypoc managed to relate this downthread completely in just one sentence, because they're better at this than I am, so maybe track that comment down for more information).
It is actually not a big deal that you're wrong --- people get the properties CBC IVs (which can't be monotonic counters) and CTR nonces (which can) confused all the time. It's why I get hives when libraries refer to the CTR nonce as an "IV".
But you didn't just get this wrong. You said the person who reported the bug "didn't know what they were talking about". Again, it was you that didn't know what they were talking about. Consider apologizing.
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.
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!