Date: Mon, 9 Dec 2013 18:48:12 -0500 (EST) From: cve-assign@...re.org To: ratulg@...hat.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: CVE request: pam: password hashes aren't compared case-sensitively -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > https://bugzilla.redhat.com/show_bug.cgi?id=1038555 > > It was found that in pam_userdb module for Pam, password hashes weren't > compared case-sensitively, which could lead to acceptance of hashes for > completely different passwords, which shouldn't be accepted. > > After hashing the user's password with crypt(), pam_userdb compares the > result to the stored hash case-insensitively with strncasecmp(), which > should be avoided, as it could result in an increased possibility of a > successful brute-force attack. Use CVE-2013-7041. Just for clarification, this refers to case sensitivity of password hashes, not case sensitivity of cleartext passwords. It could conceivably be legitimate for a product to process cleartext passwords on Linux in a case-insensitive way (perhaps for compatibility with another system on which passwords are supposed to be case-insensitive). There doesn't seem to be any plausible reason for supporting case-insensitivity of password hashes. A legitimate user isn't going to try a password that hashes to one of the differently cased values. We also looked at other comments about this issue but did not assign additional CVE IDs: > From: Solar Designer <solar@...nwall.com> > Message-ID: <20131209123945.GA16680@...nwall.com> > a length comparison of the computed vs. stored hash should have been added This seems to be a suggested security improvement to address the possibility of a system that contained stored hashes with invalid lengths. We would not consider this a vulnerability fix in the traditional sense. > correct passwords may possibly be determined remotely in linear rather > than exponential time (as function of password length): > > Additionally, the length comparison, while having it is crucial, leaks > even more timing information: it tells a remote attacker whether the > tested password length is correct or not. Again, there is a possible security improvement to address computation-time information leaks that were not considered during the product design. We would not consider this a vulnerability fix in the traditional sense unless the product tried to prevent such leaks but had an implementation error. - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (SunOS) iQEcBAEBAgAGBQJSplL+AAoJEKllVAevmvms9AcIAIUfLGRdvnbmF5Dn150qmv2e OOXR1tvoaPZBlU/LIuLCLZVUTkjpY9rvla8CFrtuGwTMX9/5XjpujYzkwTovSCyp +e2jGv2dz/fcsQ7Ul0SVmIxNmxfGaOXaykphyNhiC5jrefHQrCvolb21WJxC5y+9 ohdPUSjykBkrmV3aMk9TOn9Z1jxI1fb9douh+RqPvj0TmNwkjX9iMWOEnYjE+Sk6 eXBvqv4e3RPHOa0kpUH2MvLxWD383NG8ttsU3pyTLARPgViNpWCGRb2Wt+fJgZT6 rwi2gCS8NUY+kT9oQL1b7NLlUmjRdThHZwSMpHPoQ79T49dV67TpOnqYI0IrtCw= =46gA -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.