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,
Hi, 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,
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,
Hi Small updates on the assigned CVE's: 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
Hi! This grave problem is now open for more than two months. Is there any plan to resolve this? cu AW
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
~)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
Xh24cRLO 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
Thank you for reacting quickly! begin quotation from Theodore Ts'o (in <20140112234500.GA15640@thunk.org>): So you might clone a new bug for this... Different maintainers have different preferences here - I will note that you want seperate bugs (as we do for a number of other packages). This is your decision - we try to use a fitting severity for every problem, but sometimes the cases are not so clear. 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. 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
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!
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.
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.
A new fax document for you. Please check your fax document in the attachment to this e-mail. Scanned: Fri, 30 Oct 2015 19:04:50 +0300 Scan duration: 6 seconds Author: Donald Shoemaker Filesize: 300 Kb Resolution: 500 DPI Number of pages: 8 File name: task0000572199.doc Thanks for using Interfax service!