pwgen: Multiple vulnerabilities in passwords generation

Debian Bug report logs - #726578
pwgen: Multiple vulnerabilities in passwords generation

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Yves-Alexis Perez <corsac@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: pwgen: Multiple vulnerabilities in passwords generation

Date: Wed, 16 Oct 2013 22:03:35 +0200

Package: pwgen
Severity: grave
Tags: security
Justification: user security hole

Hi Theodore,

multiple CVEs were just assigned to pwgen, following the analysis by
Solar Designer and other people (see thread at
http://marc.info/?l=oss-security&m=138015793928431&w=2)

CVE-2013-4440 non-tty passwords are trivially weak by default
CVE-2013-4441 Phonemes mode has heavy bias and is enabled by default
CVE-2013-4442 Silent fallback to insecure entropy
CVE-2013-4443 Secure mode has bias towards numbers and uppercase letters

I'm not too sure how to handle that, especially for stable releases,
since it seems major refactoring might be needed to get rid of the
weaknesses and bias.

Regards,
-- 
Yves-Alexis Perez
Debian Security

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (450, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Message #10 received at 726578@bugs.debian.org (full text, mbox, reply):

From: Raphael Geissert <geissert@debian.org>

To: Yves-Alexis Perez <corsac@debian.org>, 726578@bugs.debian.org

Subject: Re: Bug#726578: pwgen: Multiple vulnerabilities in passwords generation

Date: Thu, 17 Oct 2013 10:21:53 +0200

Hi,

On 16 October 2013 22:03, Yves-Alexis Perez <corsac@debian.org> wrote:
> I'm not too sure how to handle that, especially for stable releases,
> since it seems major refactoring might be needed to get rid of the
> weaknesses and bias.

I think it's best to write a script that uses makepasswd and is
command-line and output-compatible with pwgen.
Basically changing everything under the hood without letting others know.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net

Message #15 received at 726578@bugs.debian.org (full text, mbox, reply):

From: Steven Chamberlain <steven@pyro.eu.org>

To: 726578@bugs.debian.org

Subject: Re: Bug#726578: pwgen: Multiple vulnerabilities in passwords generation

Date: Thu, 17 Oct 2013 11:14:23 +0100

Hi,

I don't see that any major refactoring is needed, but rather the default
assumed flags are unsafe, although changing them might be incompatible
with some scripts/applications using pwgen.

CVE-2013-4440 non-tty passwords are trivially weak by default

should ideally stop using -0A by default in non-tty mode, but could
maybe warn/fail if the caller doesn't override with -nc, which has been
recommended in the man page until now.

CVE-2013-4441 Phonemes mode has heavy bias and is enabled by default

assume -s by default?  I think it uses the same character set but with
more entropy, so only a human user should notice any difference at all.
 As long as the -s flag is set *before* parsing command line flags, it
does not conflict with -0 -A -B or -v.

CVE-2013-4442 Silent fallback to insecure entropy

consider using /dev/random instead of /dev/urandom? (Debian bug #672241)
and in any case fail if it cannot be read

CVE-2013-4443 Secure mode has bias towards numbers and uppercase letters

probably the least serious issue;  -n guarantees at least one numeral,
-c guarantees at least one capital, instead of being a completely random
selection.  Sometimes necessary if the password consumer enforces such a
rule.

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

Message #20 received at 726578@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: 726578@bugs.debian.org

Subject: Re: Bug#726578: pwgen: Multiple vulnerabilities in passwords generation

Date: Wed, 23 Oct 2013 06:22:55 +0200

Hi

Small updates on the assigned CVE's:

On Thu, Oct 17, 2013 at 11:14:23AM +0100, Steven Chamberlain wrote:
> CVE-2013-4443 Secure mode has bias towards numbers and uppercase letters
> 
> probably the least serious issue;  -n guarantees at least one numeral,
> -c guarantees at least one capital, instead of being a completely random
> selection.  Sometimes necessary if the password consumer enforces such a
> rule.

This indeed was rejected, see [1] and [2].

 [1] http://marc.info/?l=oss-security&m=138247862202393&w=2
 [2] http://marc.info/?l=oss-security&m=138249250706253&w=2

Regards,
Salvatore

Message #25 received at 726578@bugs.debian.org (full text, mbox, reply):

From: Arne Wichmann <aw@anhrefn.saar.de>

To: 726578@bugs.debian.org

Subject: Ping: pwgen: Multiple vulnerabilities in passwords generation

Date: Sun, 12 Jan 2014 21:27:14 +0100

[Message part 1 (text/plain, inline)]

Hi!

This grave problem is now open for more than two months. Is there any plan
to resolve this?

cu

AW
-- 
[...] If you don't want to be restricted, don't agree to it. If you are
coerced, comply as much as you must to protect yourself, just don't support
it. Noone can free you but yourself. (crag, on Debian Planet)
Arne Wichmann (aw@linux.de)

[signature.asc (application/pgp-signature, inline)]

Message #30 received at 726578@bugs.debian.org (full text, mbox, reply):

From: Theodore Ts'o <tytso@mit.edu>

To: Arne Wichmann <aw@anhrefn.saar.de>, 726578@bugs.debian.org

Subject: Re: Bug#726578: Ping: pwgen: Multiple vulnerabilities in passwords generation

Date: Sun, 12 Jan 2014 18:45:00 -0500

On Sun, Jan 12, 2014 at 09:27:14PM +0100, Arne Wichmann wrote:
> 
> This grave problem is now open for more than two months. Is there any plan
> to resolve this?

First, the CVE about having the unavailability of /dev/random fail
hard -- sure, that should be a separate bug since that's a fix that I
think is reasonable at this point.  We can now guarantee that
/dev/random exists everywhere.  (And by that same token, if an
attacker can cause /dev/random not to be present, they probably have
root, so you're probably toast anyway.  So I don't think it's going to
really improve things to remove the drand() fallback, but I don't have
strong feelings about that.)


Secondly, I'll note that one of the CVE's were rejected as not a
vulnerability.  (In general it would have been better to have opened
seperate bugs for each CVE.)

Finally, whether you think the other two CVE's justify this to be
serious, let alone "grave" bug really depends on what you think the
goals of pwgen are.  To quote from the manual page:

    The  pwgen  program generates passwords which are designed to be easily
    memorized by humans, while being as secure  as  possible.   Human-memo‐
    rable  passwords  are  never  going  to be as secure as completely com‐
    pletely random passwords.  In particular, passwords generated by  pwgen
    without  the  -s option should not be used in places where the password
    could be attacked via an off-line brute-force attack.    On  the  other
    hand,  completely  randomly  generated  passwords have a tendency to be
    written down, and are subject to being compromised in that fashion.

So we could change the defaults to be "pwgen -csy 20", in which case
you would get passwords like tihs:

L}U@lc_~i^>n|ro!4uI- 1`;yXlYVMW%?E9)3A&7G **}6BoBu=!~3)y?3v]Or
>=>:PC;H?E7*+6$c&-QH URGgjUNG[\dSw\>p7F-] _AXZ~(HYd8Q#%b>!]'u:
~)0<I-{)}_Ya*Q2nlWN; ^#t~1/'sf@*xz9GOhBuv e_[-_Fe{CD#]DY8&@M^a

I'm not sure that would be an improvement, as simply no one would use
them.

OK, how about this?  (Generated using pwgen -s).

vQ6uwkMk lSswO2MB tA8dYPpl KU1pQ2Xh 2XfxRyrC Za2xKx7h psPwHZ0c dOsC0JBX
JY3udA9c t6LzoiUq M0jR3AoS GOHkNE7G TeThsZz1 6cVi4ayY Poe4hPj7 o2a7OpPC
Xh44cRLO 1chQyseV 6c2k0O3B OkdgRxy4 K6Vc4JY2 ylO3IE9B gVvNxw6B 7wjcOXwF

Again, this will make the professional paranoids happy (although
perhaps not as happy as ">=>:PC;H?E7*+6$c&-QH"), but its not clear that
real users would be any less likely to write "ylO3IE9B" on a sticky
note which is pasted to their monitor, or just in a "passwords" file
in their home directory.

So ultimately, a lot of this is about an argument over defaults, and I
think the higher level problem is that no matter what password policy
you use, passwords are doomed as a technology.  Anything which is
secure against a brute force attack is impossible for a user to use,
unless they share passwords across multiple sites so they only have to
remember one password such as "ylO3IE9B" --- at which point they get
toast once some web site screws up in some way and gets penetrated by
bad guys.

					- Ted

Message #35 received at 726578@bugs.debian.org (full text, mbox, reply):

From: Arne Wichmann <aw@anhrefn.saar.de>

To: Theodore Ts'o <tytso@mit.edu>

Cc: 726578@bugs.debian.org

Subject: Re: Bug#726578: Ping: pwgen: Multiple vulnerabilities in passwords generation

Date: Tue, 14 Jan 2014 12:08:11 +0100

[Message part 1 (text/plain, inline)]

Thank you for reacting quickly!

begin  quotation  from Theodore Ts'o (in <20140112234500.GA15640@thunk.org>):
> On Sun, Jan 12, 2014 at 09:27:14PM +0100, Arne Wichmann wrote:
> > This grave problem is now open for more than two months. Is there any plan
> > to resolve this?
> 
> First, the CVE about having the unavailability of /dev/random fail
> hard -- sure, that should be a separate bug since that's a fix that I
> think is reasonable at this point.  We can now guarantee that
> /dev/random exists everywhere.  (And by that same token, if an
> attacker can cause /dev/random not to be present, they probably have
> root, so you're probably toast anyway.  So I don't think it's going to
> really improve things to remove the drand() fallback, but I don't have
> strong feelings about that.)

So you might clone a new bug for this...

> Secondly, I'll note that one of the CVE's were rejected as not a
> vulnerability.  (In general it would have been better to have opened
> seperate bugs for each CVE.)

Different maintainers have different preferences here - I will note that
you want seperate bugs (as we do for a number of other packages).

> Finally, whether you think the other two CVE's justify this to be
> serious, let alone "grave" bug really depends on what you think the
> goals of pwgen are.  To quote from the manual page:

This is your decision - we try to use a fitting severity for every problem,
but sometimes the cases are not so clear.

>     The  pwgen  program generates passwords which are designed to be easily
>     memorized by humans, while being as secure  as  possible.   Human-memo???
>     rable  passwords  are  never  going  to be as secure as completely com???
>     pletely random passwords.  In particular, passwords generated by  pwgen
>     without  the  -s option should not be used in places where the password
>     could be attacked via an off-line brute-force attack.    On  the  other
>     hand,  completely  randomly  generated  passwords have a tendency to be
>     written down, and are subject to being compromised in that fashion.
> 
> So we could change the defaults to be "pwgen -csy 20", in which case
> you would get passwords like tihs:
> 
> L}U@lc_~i^>n|ro!4uI- 1`;yXlYVMW%?E9)3A&7G **}6BoBu=!~3)y?3v]Or
> >=>:PC;H?E7*+6$c&-QH URGgjUNG[\dSw\>p7F-] _AXZ~(HYd8Q#%b>!]'u:
> ~)0<I-{)}_Ya*Q2nlWN; ^#t~1/'sf@*xz9GOhBuv e_[-_Fe{CD#]DY8&@M^a
> 
> I'm not sure that would be an improvement, as simply no one would use
> them.
> 
> OK, how about this?  (Generated using pwgen -s).
> 
> vQ6uwkMk lSswO2MB tA8dYPpl KU1pQ2Xh 2XfxRyrC Za2xKx7h psPwHZ0c dOsC0JBX
> JY3udA9c t6LzoiUq M0jR3AoS GOHkNE7G TeThsZz1 6cVi4ayY Poe4hPj7 o2a7OpPC
> Xh44cRLO 1chQyseV 6c2k0O3B OkdgRxy4 K6Vc4JY2 ylO3IE9B gVvNxw6B 7wjcOXwF
> 
> Again, this will make the professional paranoids happy (although
> perhaps not as happy as ">=>:PC;H?E7*+6$c&-QH"), but its not clear that
> real users would be any less likely to write "ylO3IE9B" on a sticky
> note which is pasted to their monitor, or just in a "passwords" file
> in their home directory.

I do not have a really good idea on how to handle this. Some ideas come to
mind, mostly inspired by [1]:
- Improve the algorithm to be less biased. Though I see that would not be
  easy.
- Warn about the bias
- Use -s as default

[2] suggests, that there is a patch out there, but I have not yet looked at
it.

> So ultimately, a lot of this is about an argument over defaults, and I
> think the higher level problem is that no matter what password policy
> you use, passwords are doomed as a technology.  Anything which is
> secure against a brute force attack is impossible for a user to use,
> unless they share passwords across multiple sites so they only have to
> remember one password such as "ylO3IE9B" --- at which point they get
> toast once some web site screws up in some way and gets penetrated by
> bad guys.

I see the point, but that does not make the problem go away, and in many
cases you do not have so much of a choice, so the program does still have
its points.

CVE-2013-4440 has an easy fix, isn't it?

[1] http://www.openwall.com/lists/oss-security/2012/01/19/24
[2] http://marc.info/?l=oss-security&m=138015793928431&w=2

cu

AW
-- 
[...] If you don't want to be restricted, don't agree to it. If you are
coerced, comply as much as you must to protect yourself, just don't support
it. Noone can free you but yourself. (crag, on Debian Planet)
Arne Wichmann (aw@linux.de)

[signature.asc (application/pgp-signature, inline)]

Message #40 received at 726578@bugs.debian.org (full text, mbox, reply):

From: Adam Borowski <kilobyte@angband.pl>

To: 726578@bugs.debian.org

Subject: please tell me how is this a vulnerability

Date: Tue, 21 Oct 2014 11:57:52 +0200

[Message part 1 (text/plain, inline)]

Control: tags -1 +patch

So... how exactly are these vulnerabilities?

2. is what this program is supposed to do: produce _pronounceable_ passwords
instead of pure line noise.  Sure, these do have less entropy than pure line
noise for the same length, but the point is to make something that's
possible to remember.  If I wanted fully random unbiased ASCII characters,
I'd use a perl one-liner instead of a complex generator like pwgen.

As for 4., as Steven remarked, this is done intentionally to placate
"password quality checkers".  Also, while allowing an all-lowercase password
2^-8 of the time does have negligibly more resilience against an exhaustive
attack, it is massively worse against attacks prevalent in the real world. 
Thus, paying this small amount of entropy is well worth it.

And as for 3., please read http://www.2uo.de/myths-about-urandom/
Heck, FreeBSD doesn't even _have_ /dev/random in Linux's sense -- and no one
is calling it insecure.

So these three points are complete non-issues.


I do agree with 1., though, so here's a patch to fix it.

Let's have pwgen in jessie!

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.

[pwgen-notty.patch (text/x-diff, attachment)]

Message #47 received at 726578@bugs.debian.org (full text, mbox, reply):

From: Adam Borowski <kilobyte@angband.pl>

To: 726578@bugs.debian.org

Subject: CVE-2013-4442 is not about /dev/random vs /dev/urandom

Date: Mon, 27 Oct 2014 16:34:59 +0100

It looks like this bug does mischaracterize CVE-2013-4442.  Unlike what's
said here, using /dev/urandom instead of /dev/random (which contrary to
popular wisdom is not an issue) but that, if opening of these two devices
fail, pwgen falls back to using pids and time.

On BSD and Linux/GNU, /dev/urandom is guaranteed so this might trigger if:
* someone exhausts the system-wide descriptor limit
* a chroot lacks the /dev entries
* the admin writes a pathologically bad selinux policy

Let's track this as a separate bug.  I'd say that this is only a minor
vulnerability, thus let's have it at "important" severity.  pwgen has at
least one RC issue, so it wouldn't be bad to fix for jessie but I don't find
it as a must.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.

Message #52 received at 726578@bugs.debian.org (full text, mbox, reply):

From: Adam Borowski <kilobyte@angband.pl>

To: 726578@bugs.debian.org

Subject: remaining issues are non-bugs

Date: Mon, 27 Oct 2014 17:00:05 +0100

Control: severity -1 important

I have split two parts into separate bugs, I think the remainder are ok:

CVE-2013-4440 non-tty passwords are trivially weak by default
* #725507, my assessment: grave
CVE-2013-4441 Phonemes mode has heavy bias and is enabled by default
* works as designed
CVE-2013-4442 Silent fallback to insecure entropy
* #767008, my assessment: important
CVE-2013-4443 Secure mode has bias towards numbers and uppercase letters
* REJECTED, actually improves security!

CVE-2013-4443 has been rejected from the CVE database.

So let's discuss CVE-2013-4441.  Such a bias means the program does what
it's designed to do: it produces pronounceable passwords rather than a pure
line noise.  These are not necessarily less secure -- you just need a longer
length than on line noise.  Recently this has been popularized as the
"correct horse battery staple" issue: long passwords are far, far easier to
memorize for a human than shorter but more complex ones, while being capable
of providing as much or more entropy.

What remains is that pwgen's default length, 8 characters, might been
adequate when the program was written, but is insecure today.  But let's
discuss that elsewhere.

So I think this bug should be closed.  Being not a security expert myself,
I'm merely degrading it to "important" for now, until someone else can
confirm and close.

I'll bump #725507 to grave after the next britney run.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.

Send a report that this bug log contains spam.