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.
Created pam tracking bugs for this issue:
Affects: fedora-all [bug 1038557]
Created attachment 833081 [details]
Patch for this vulnerability.
This patch was given at the debian page to solve this issue.
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:
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.
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.
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/ .
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.