Bugzilla – Bug 846397
VUL-0: CVE-2013-4440: pwgen silent fallback to insecure entropy
Last modified: 2014-12-09 12:16:07 UTC
CVE-2013-4440 tracker ticket for: CVE-2013-4441 CVE-2013-4442 CVE-2013-4443 Pwgen was found to silently falling back to use standard pseudo generated numbers on the systems that heavily use entropy. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4440 https://bugzilla.redhat.com/show_bug.cgi?id=1020220 http://seclists.org/oss-sec/2013/q4/116 http://www.openwall.com/lists/oss-security/2012/01/17/12 http://marc.info/?l=oss-security&m=137049241132104&w=4 (seems to be a patch here saying it fixes most of the issues) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672241 http://comments.gmane.org/gmane.comp.security.oss.general/10265
bugbot adjusting priority
CVE-2013-4443 was disputed (rest are still alive) From: Solar Designer <solar@openwall.com> Date: Wed, 23 Oct 2013 01:50:13 +0400 On Fri, Oct 18, 2013 at 12:28:18PM +1100, Michael Samuel wrote: > On 16 October 2013 16:59, Kurt Seifried <kseifried@redhat.com> wrote: > > CVE-2013-4443 pwgen Secure mode has bias towards numbers and uppercase > > letters > > Solar Designer picked up that this one should probably not have been assigned. Michael is referring to discussion that we had off-list. My current understanding, based on Michael's messages only, is that the bias was only at character level, but not at full password level, given the policy-reduced keyspace. I'll illustrate this by a trivial example: Suppose we have a password generator configured to produce two character long passwords consisting of lowercase and uppercase letters. It can produce four kinds of passwords: LL, LU, UL, UU, where the L's and U's denote lowercase and uppercase letters. These four kinds have equal probability, and so do the individual L's and U's. Now let's add some policy enforcement into the generator: have it require at least one uppercase letter. Let's have it implement that by generating a new password unless and until the generated password meets the policy, and only then to print the password. This generator may now produce LU, UL, and UU. It is easy to see that U is now more common than L, however this is not a security issue on its own (arguably, the keyspace reduction might be, but it is expected). If we look at the full passwords within this reduced keyspace, then it is also easy to see that all three of LU, UL, and UU are still equally likely. So there's no password-level bias, and this is normally the only kind of bias that would actually matter for security. Thus, no security issue (other than the expected keyspace reduction). The same applies to longer passwords and to additional character classes, such as, if I understand its behavior correctly, to pwgen's "secure" mode passwords. Michael, is the above correct? If so, should Kurt reject CVE-2013-4443? I think so.
This is an autogenerated message for OBS integration: This bug (846397) was mentioned in https://build.opensuse.org/request/show/264518 Factory / pwgen
fixed for factory. too unimportant for older products in my eyes