Bug 1038555 (CVE-2013-7041) - CVE-2013-7041 pam: pam_userdb case insensitive password hash comparison
Summary: CVE-2013-7041 pam: pam_userdb case insensitive password hash comparison
Alias: CVE-2013-7041
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1038557 1074690
Blocks: 1038571
TreeView+ depends on / blocked
Reported: 2013-12-05 10:40 UTC by Ratul Gupta
Modified: 2021-06-16 15:04 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2021-06-16 15:04:00 UTC

Attachments (Terms of Use)
Patch for this vulnerability. (623 bytes, patch)
2013-12-05 10:44 UTC, Ratul Gupta
no flags Details | Diff

Description Ratul Gupta 2013-12-05 10:40:50 UTC
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.


Comment 1 Ratul Gupta 2013-12-05 10:43:43 UTC
Created pam tracking bugs for this issue:

Affects: fedora-all [bug 1038557]

Comment 2 Ratul Gupta 2013-12-05 10:44:52 UTC
Created attachment 833081 [details]
Patch for this vulnerability.

This patch was given at the debian page to solve this issue.

Comment 3 Vincent Danen 2013-12-10 16:53:46 UTC
Just as an FYI, Solar Designer made some additional observations about the probable unsuitability of continuing to ship this module.  It is probably worth looking into:


Comment 4 Tomas Mraz 2013-12-11 08:41:45 UTC
Note that if pam_fail_delay module is used together with pam_userdb the timing information in case of failures is not really leaked as there would be additional random delay added. Of course to be sure on this we would have to properly statistically analyze the timing to find whether there still isn't some remaining timing leak not sufficiently masked by the random delay.

Comment 8 Tomas Hoger 2014-05-16 20:41:09 UTC
Upstream fix:


Comment 9 Tomas Hoger 2014-05-19 21:03:56 UTC
The versions of pam_userdb module shipped with the pam packages in Red Hat Enterprise Linux 6 and earlier only support crypt passwords using the traditional Unix DES based password hashing.  Support for newer hashes supported by underlying glibc crypt() was only added upstream via the following commit:


DES based hashes consist of 13 characters out of the following set [a–zA–Z0–9./].  The first two characters are salt characters.  Remaining 11 characters are password hash.  This hash is base64 encoded output of 64 bit value from the DES encryption.

In the context of this flaw, salt characters are fixed - they are extracted from the hash value stored in the password database file and can not be influenced by an attacker trying a brute force attack.  Hence collisions happen when the hash of different password only differs in case of one or more alphabetical characters in the remaining 11 characters.  The maximum number of possible collisions depends on the number of alphabetical characters in those 11 bytes.  If all are alphabetical, there are 2048 (2^11) hashes with only different case.  As mentioned above, password hash is base64 encoded, hence there's only ~10% (52^11 / 64^11) probability that all 11 characters are lower or upper case letters.  For hashes with numbers or '/' and '.', the number of possible collisions is lower.

In DES based hashing, user password is used to generate 56 bit key for DES encryption (passwords are truncated to 8 characters, only 7 bits of each character is used to for the key).  Hence even though resulting hash is 64 bit value, there are only 2^56 valid hashes for a given salt value.  Out of all possible 11-characters strings containing characters listed above, only 1/256 of them are valid DES hashes.  Considering this, the expected number of valid collisions in the ideal case drops to 8 (2048/256).

Further on, some of these colliding hashes are likely to be for passwords that include special characters that are not typically used in passwords, or may not even be accepted as valid password characters by programs reading user passwords.  Assuming English keyboard, the number of characters to be used in password is less than 100 (this includes whole English alphabet, all numbers, and all punctuation/special characters).  Extending this character set to all 7 bit characters implies extending space of all possible passwords more than 7 times.  Hence even in the mentioned ideal case, it is expected that there is less than 1 colliding string that is a valid hash of a password that only contains characters typically used in passwords.

Even without considering any other optimization brute force attack is likely to use (such as trying likely / dictionary passwords first), benefits to the attack this flaw offers are negated by the increased password search space.

Comment 10 Tomas Hoger 2014-05-19 21:05:19 UTC

This issue affects the versions of pam as shipped with Red Hat Enterprise Linux 5 and 5. The Red Hat Security Response Team has rated this issue as having Low security impact. A future update may address this issue. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/ .

Comment 11 Fedora Update System 2014-12-18 06:07:48 UTC
pam-1.1.8-2.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 13 Product Security DevOps Team 2021-06-16 15:04:00 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):


Note You need to log in before you can comment on or make changes to this bug.