Hacker News new | comments | ask | show | jobs | submit login
7-zip broken password random number generator (threadreaderapp.com)
168 points by wyday 26 days ago | hide | past | web | favorite | 64 comments



This is getting a lot of play today on Twitter but it's not all that consequential in the normal setting of a ZIP file.

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.


> It would be nice if there was a mainstream, built-in way to password-protect a file that you could share with someone else

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.


Or just use GnuPG


Yep, there are a lot of ways you can do it. The point is, what are the chances my accountant is going to have GnuPG already installed on their laptop versus MS Word?


None, is the answer. There is a none percent chance. And if you're going to get someone to install something, it's not going to be GPG. Without loss of generality this applies as well to lawyers, IT managers, development leads, chief security officers, cryptographers, and some former PGP developers.


It's a simple install and even has a GUI app for right-click support.


Nice method! But it's surprisingly similar to https://xkcd.com/763/ .


> 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.

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).


In this case the vuln applies to 7z format, it also uses cbc with same weak rng iv.


Coupled with the very simplistic and predictable passwords often encountered in passworded (avoiding the word "encrypted") ZIPs, I often have the impression that the intention is more to add an explicit human step to open the ZIP. So, making it (less) accessible to crawlers, or give a non-malicious recipient a moment to think whether they want/need/should extract this.

Often the password comes in the same mail or website, after all.


I got a chance to ask the guy who invented the ZIP encryption scheme a couple of years back, and he basically said it was designed to be exportable under the US's encryption export restrictions at the time, which I understood to mean they made it intentionally weak.


> 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.

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.


I agree, this is a good attack to game out.


Whatever the excuses, this is just stupid because it is so easy to get right. Don’t invent your own random number generator, use the one from the OS.


Keep in mind that 7-Zip is a fairly old app - it first shipped two years before Windows XP, which also happens to be the first version of Windows that had cryptographic APIs, and in particular, CryptGenRandom.


I mean, yeah, 7z should fix this, but they're still going to be using unauthenticated CBC, which is a much bigger problem, so I'm going to have a hard time getting too worked up about this.


So your argument is that 7z's insecure AES encryptor is not a problem because nobody _should_ use it?


It's not a problem because nobody does use it in a setting where this is a practical problem. Somebody could use it that way. They shouldn't.

(My confidence here is high but not absolute).


: unless you're absolutely sure otherwise, you should always assume any ZIP program you're using doesn't actually encrypt password-protected ZIPs.

so 7zip AES is not actually AES? Obviously the source code shows it is


His point is that “zip” is an old data packaging format first, encrypted bundle second, many aeons ago the decryption was purely based - think “authenticated” PDFs that were plain text, but the application was meant to ask for a password before displaying the content.

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.


7-Zip has its own format, completely distinct from ZIP.


>I thought about reporting this at 7zip Sourceforge forums but then I vomited again when I saw a long thread of largely incoherent exchanges on how 7z should be using Twofish instead of AES-256 because...

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


Hi! I've reported it already on 7zip Sourceforge page. No response. In the forums I saw a thread someone had already started where the author said it's better to save 8bytes per archive than fix the IV ¯_(ツ)_/¯


Well, at some point you get tired communicating with tinfoils, and it's reasonable to expect that author just didn't have a motivation/incentive to even start. Better spend time for something more productive.


It is not clear if anything is actually wrong here. It would be nice if someone who has spent more than "30 minutes" looking at this code could verify these claims and publish an article explaining the implications of these design choices.

The twitter thread that this is aggregated from has replies that seem to indicate that there is no practical exploit here.

https://twitter.com/3lbios/status/1087848040583626753


On the other hand, using the system cryptographic RNG (/dev/urandom, CryptGenRandom) is probably less effort than it took to write this strange half-baked RNG.


Yup, if you want to see the state of the art in this, here it is from libsodium:

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


It seems they use getrandom() on FreeBSD too:

    # if defined(__FreeBSD_version) && __FreeBSD_version >= 1200000
    #  include <sys/random.h>
    #  define HAVE_LINUX_COMPATIBLE_GETRANDOM


CryptGenRandom first appeared in WinXP.

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.


This likely happened because 7-zip is Windows-centric, and the p7zip packages for UNIXish systems are assembled afterwards.


I hear this argument again and again: "there's no exploit, or show one".

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.


It is obviously wrong to have a CBC IV that is straightforwardly predictable.


not a cryptographer: but from memory the main quality important in an IV for CBC is that it isn't reused for the same key (chosen plain-text attacks aside)

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)


In Common Encryption (encrypted mp4 files) 8 bytes IVs are a fully supported and documented. And sometimes preferred for compatibility. CENC mode even uses CTR, so the IV is simply incremented every block.


Correct, the guy on twitter doesn’t seem to know what he is talking about.

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.


No, I think you might be the one who doesn't seem to know what they're talking about, unfortunately. I think you have CBC mode confused with CTR (and its derived modes). CBC IVs need to be unpredictable, CTR nonces need to never repeat. Neither IVs nor nonces need to be secret, but it's important not to be able to predict an IV before it's used.


What? Even for an encrypted 7zip archive? How does predicting a past event make sense here? Maybe you know an attack I’m not aware of. This isn’t an interactive protocol.

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?


No. You wrote "there is no security dependency on it [a CBC IV] being random". That is plainly false --- in fact, it's Wikipedia false --- you can literally just go to Wikipedia and search for the word "unpredictable" to see why. People do indeed use random CTR nonces as a way to ensure they never reuse them. But that's not why they randomize CBC IVs. There's a Cryptopals challenge about this if you'd like to play with the concept more.

('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.


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.


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!


The attack here is:

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.


Monotonically increasing CBC IVs are in fact not fine; you have them confused with CTR nonces, which need single-use rather than unpredictability. See Bard for more details of the best-known attack on predictable IVs. If you're going to try to take someone down a peg, be right.


They are if you don't have an oracle afaik


I don't follow your response. If you're wondering whether it's OK to have predictable IVs, check:

* 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.


If you reuse an IV on 2 files at rest, information that both files have the same prefix leaks. If you use a counter IV, or a random IV, you got nothing -- that's the only point I'm making ivs don't have to be random in the confines of the right context


You should read about the attacks tptacek mentioned. If IVs are predictable, it's the same impact as if you reuse the same IV, you just have to compute (m' xor IV' xor IV) instead of just m' if IV' = IV Then in both cases you check if c' = c


It seems every few months we hear a story about something which is supposed to be secure not actually being secure or secure as expected.

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.


Not exactly the same, but the EU has commissioned audits and just started a bug bounty program on some important open source projects.

https://juliareda.eu/2018/12/eu-fossa-bug-bounties/


Cryptography doesn't quite work that way. Just because recovering cleartext is not feasible in some specific case does not make a cryptosystem secure in general.


In fact, that's basically what Telegram did with their impossible "crypto contests": provide a specific attack scenario, promise lots of money to break that (impossible) scenario, and then claim that it is secure against all possible attacks.


That seems interesting. Do you have any links explaining the situation?



> Open-source "many eyes have looked at it for years so it must be secure" crypto code.

Nobody claims this. Open source code is just easier to audit than non-open code.


Well, in the past it was one of the main arguments in favor of open source. There is even a related article on the WP: https://en.wikipedia.org/wiki/Linus%27s_Law (it has nothing to do with Linus though)


No, it's not and has never been; you have it backwards. Closed-source code is guaranteed[0] to be insecure, open source code may or may not be secure. New open source code is almost certainly insecure for much the same reasons closed code is insecure, but trends toward security over time as more people inspect it and fix security holes.

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.


I don't claim that the "Linus's law" is true, I only point out it was used by some open source evangelists. It took decades and a few high-profile bugs to show it's not that simple.

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.


Linus's law says that if enough people look at something, the bugs will appear. But often not very many people are actually looking at the source code of open source software. So there is no contradiction here.


Heavy emphasis on "in the past," and probably also, "ESR claimed."


Yes, and the article itself is an example of this.


The way this is written reminds me why I try to never interact with security people in any social or professional situation, ever.

When is the insufferably arrogant techno mage trope going to die?


> When is the insufferably arrogant techno mage trope going to die?

Probably at the same time as insufferably bad software engineering dies


Addressing the debate this thread seems to have spawned, a practical attack on predictable CBC IVs is described here:

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.


knowing the IV does not allow one to crack the message https://stackoverflow.com/questions/3225640/how-to-decrypt-a...

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


Once again, no, CBC IVs need to be unpredictable.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: