mailing list archives
Re: RESEND: CVE Request: pwgen
From: Kurt Seifried <kseifried () redhat com>
Date: Tue, 15 Oct 2013 23:59:59 -0600
-----BEGIN PGP SIGNED MESSAGE-----
On 10/11/2013 09:34 PM, Solar Designer wrote:
Kurt, Steve, all -
On Thu, Oct 10, 2013 at 03:35:09PM +0200, Marcus Meissner wrote:
It might just not be that CVE worthy. But I saw no replies...
I now think it is CVE worthy.
(CVE worthyness: It does not fully meet the security expectations
of generating a non-weak password by default.... )
Kurt was "sitting on the fence for this one":
At the time, I replied that it was too early for the CVE aspect, as
I was still figuring out the magnitude of the problem:
Steve replied that having an insecure feature documented does not
always preclude from CVE assignment:
To this, I can add that although the phoneme mode is documented as
being less secure, the magnitude and ways in which it is less
secure are unclear from the documentation. Specifically, there's
no mention that the distribution of generated passwords is highly
non-uniform, and indeed this is not clear from merely looking at a
handful of passwords. (I guess this non-uniformity was not expected
by the author, and thus it is a bug.)
Also, without looking at the documentation, it is not even
immediately clear (to a new user of the program) that phonemes are
being used. At first glance, the passwords look like they could
potentially use the full 62^8 keyspace - but this is actually not
the case, by far. So the program's default behavior is
The thread ended here, with some figures showing just how bad the
The CVE aspect was not revisited.
Here are the figures for pwgen's defaults with output to tty:
Top 1 million of unique passwords from my 1 billion training set
cracks 3.7% of passwords in the test set.
Top 10 million cracks 14.5%.
Top 44 million cracks 21%. (I chose this as an optimal wordlist
Top 100 million cracks 26.3%.
With pwgen's defaults with output to non-tty:
Top 45.5 million cracks 75%. (Ouch!)
These results can be improved a little bit (slightly higher
percentages cracked per same wordlist size) by using a larger
training set (beyond 1 billion) or by considering all of the
phoneme probabilities, etc. and creating a program that would
output pwgen's possible passwords in an optimal order (this proves
to be a non-trivial task so far, yet someone may do it).
On Thu, Sep 26, 2013 at 11:11:59AM +1000, Michael Samuel wrote:
No CVEs have been assigned for this, and as far as I can tell
no distributions have patched.
On 6 June 2013 14:19, Michael Samuel <mik () miknet net> wrote:
I've done some further analysis of the program after reading
the previous thread, and I think there needs to be CVEs and
- When used from a non-tty passwords are trivially weak by
default (first reported by Solar Designer) - Phonemes mode
has heavy bias and is enabled by default (first reported by
Solar Designer) - Silent fallback to insecure entropy (first
reported by Jean-Michel Vourg?re) (Debian bug #672241 -
tagged as "wishlist") - Secure mode has bias towards numbers
and uppercase letters
I've attached a patch that fixes most issues - it doesn't
solve the bias towards numbers, because it's caused by
requiring at-least one number per password - so in an 8
character password there'd have to be 0.1 numbers to avoid
bias. There's an argument to be made for removing the
at-least-one rule, but if the system that password is being
used with has those rules, it doesn't fix the problem anyway.
Perhaps a separate flag for that?
The changes are:
- Print a message and abort() of there's trouble opening or
reading /dev/urandom (So apport should pick up any packages
that have been using insecure entropy) - Make "-s" the
default - Add an argument --insecure-phonemes (or -P) -
Non-tty passwords are now as secure as tty - Require
lower-case characters be present to even out some bias - Pull
in passwdqc as a Suggests on the debian package - pwqgen can
generate sane random passphrases
I can't imagine any reasonable use-case for the non-tty
defaults (except maybe combining with espeak as an enhanced
interrogation technique), and you can be certain that there's
some people out there with it embedded in a script that's
generating useless passwords.
For phonemes mode in general, the bias is extreme, there are
a limited number of possible combinations and it is generally
not suitable for security purposes. I have some fairly
detailed analysis of it, but I believe this list has a
Welp I can't argue with data (well I could, but that would be silly).
CVE-2013-4440 pwgen non-tty passwords are trivially weak by default
CVE-2013-4441 pwgen Phonemes mode has heavy bias and is enabled by default
CVE-2013-4442 pwgen Silent fallback to insecure entropy
CVE-2013-4443 pwgen Secure mode has bias towards numbers and uppercase
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
-----END PGP SIGNATURE-----