Re: RESEND: CVE Request: pwgen

[Kurt Seifried <kseifried () redhat com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.... )
> >
> > Solar? Kurt?
>
> Kurt was "sitting on the fence for this one":
>
> http://www.openwall.com/lists/oss-security/2012/01/17/12
>
> 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:
>
> http://www.openwall.com/lists/oss-security/2012/01/17/14
>
> Steve replied that having an insecure feature documented does not
> always preclude from CVE assignment:
>
> http://www.openwall.com/lists/oss-security/2012/01/17/15
>
> 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
> misleading.
>
> The thread ended here, with some figures showing just how bad the 
> problem is:
>
> http://www.openwall.com/lists/oss-security/2012/01/22/6
>
> 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
> size.)
>
> 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).
>
> Alexander
>
> > On Thu, Sep 26, 2013 at 11:11:59AM +1000, Michael Samuel wrote:
> > > Hi,
> > >
> > > 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
> > > > fixes for:
> > > >
> > > > - 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
> > > > no-exploits policy...
> > > >
> > > > Regards, Michael

Welp I can't argue with data (well I could, but that would be silly).

Please use:

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
letters


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

iQIcBAEBAgAGBQJSXiteAAoJEBYNRVNeJnmTDn0P/2uUVFMCYJcJ8L5vWWAlrSG5
n10+s7NqviQ/qrRh+zkgM1kYpFropXrRJgjqschANmP04DbUoo1j4dYFAkO4EwFQ
FYgic/DmOO/XD6KNkd6NLl4HQIp0ceTabO0uubBWheL0uCH+GFP4MhGBPMmGeyOs
JKLCM5EK7KfzZY8bIEfkoU0qiPZGqPNTnjxW+wFVVY9cgnkuQ7yrmZVjN3uc0jfK
MEOsZQ2dLCru4Sh+AS+2xlkNO6DxgxpuH0uHONm88hEbm0Uvg7pb8oiLQpooNUKt
BCetRvr2nZqxVysjUzzs9OL0IDdnqP/ItAT4a1Bi2s+GVhlfWPMr6zbjo/47sP4X
IFeGUnb0XCA06l4lSxyqm/NDIxxx/vO13kCIeVmjj7lUn28qu/A2Mj/e/xEN38QU
joC1h3CLsRfCr8c0ZVBos4yH4vt4Ex1aMNBtghb64mB5oG0WHzjov3HmODieqVIk
YkvAbLeX88rQFNkoO6VuQzIG1v95Gn0XR/MU/wIf+zMLbgCGkWI6gGLk1Rgg2ARJ
VejHsrXjOIcJRaHQ9AfE5Ye54efVvfmZrHA9IXmdZB/VgI6DdGLzIlZSgqGHP0E2
C/nTvaHBNlOPtFyL8Dep4h83JSvlmWNPoLMfDwbPMQVQ3mt4F/HZH/ST2vzdnlLt
C3eVQaCGgtX/+eNGHJUR
=dq17
-----END PGP SIGNATURE-----