
7-zip broken password random number generator - wyday
https://threadreaderapp.com/thread/1087848040583626753.html
======
tptacek
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.

~~~
13of40
> 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.

~~~
techntoke
Or just use GnuPG

~~~
13of40
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?

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

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

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

~~~
3lbios
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 ¯_(ツ)_/¯

------
deckar01
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](https://twitter.com/3lbios/status/1087848040583626753)

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

~~~
shittyadmin
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...](https://github.com/jedisct1/libsodium/blob/master/src/libsodium/randombytes/sysrandom/randombytes_sysrandom.c#L335)

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

~~~
loeg
It seems they use getrandom() on FreeBSD too:

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

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

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

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

~~~
lawnchair_larry
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?

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

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

~~~
tptacek
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!

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

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

~~~
matthewaveryusa
They are if you don't have an oracle afaik

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

~~~
matthewaveryusa
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

~~~
garypoc
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

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

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

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

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

~~~
whyever
[https://hackerfall.com/story/a-crypto-challenge-for-the-
tele...](https://hackerfall.com/story/a-crypto-challenge-for-the-telegram-
developers-1)

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

~~~
dvfjsdhgfv
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](https://en.wikipedia.org/wiki/Linus%27s_Law)
(it has nothing to do with Linus though)

~~~
a1369209993
No, it's not and has never been; you have it backwards. _Closed-source_ code
is guaranteed[0] to be _in_ secure, 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.

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

------
endofcapital
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?

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

Probably at the same time as insufferably bad software engineering dies

------
technion
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...](https://stackoverflow.com/questions/3008139/why-is-using-a-non-random-
iv-with-cbc-mode-a-vulnerability)

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.

------
paulpauper
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-aes-
cbc-with-known-iv)

[https://stackoverflow.com/questions/3225640/how-to-
decrypt-a...](https://stackoverflow.com/questions/3225640/how-to-decrypt-aes-
cbc-with-known-iv)

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

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

