Bug 3898
| Summary: | md5 passwords are broken | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Kostas Georgiou <k.georgiou> |
| Component: | pam | Assignee: | Cristian Gafton <gafton> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.0 | CC: | franz.sirl-kernel, mgalgoci, mkp |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | sparc | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 1999-08-24 01:00:31 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Kostas Georgiou
1999-07-05 03:45:02 UTC
i just found out that gdm has the same problem, same patch again Ok. Fixed in my gdm2 devel tree. Changed symbol names to avoid polluting PAM's name space as well. -- Martin *** Bug 4074 has been marked as a duplicate of this bug. *** This bug was reported by Andrew V. Nikulin <andrew> I have the patch file saved in my home directory. The tarball is called pam_patch.tgz --MJG Andrew writes: "I discovered a serious enough bug in pwdb and pam packages. So, yesterday I've killed the entire day trying to understand why sshd2 doesn't work correctly on my Ultra SPARC box, but it works fine on Intel (both under RedHat Linux 6.0). After a few sessions with ltrace, gdb and other tools I've finally understood that a problem appears only when MD5 hashes are enabled in pam_pwdb module. Digging sources of pam_pwdb, pwdb and sshd2 I've got next thing: pwdb and pam use their own routine crypt_md5() for MD5 calculation, but sshd2 uses standart crypt() from GLIBC for such purpose. I wrote a short test program, which simply encrypts the phrase "magic_word" with salt "$1$xx", calling GLIBC crypt() and pam_pwdb crypt_md5(). After running this program on SUN and Intel I've got the following results: Intel: pam_pwdb crypt_md5(): $1$xx$ipOG9IJsAo23Ba44.YOUd1 GLIBC crypt(): $1$xx$ipOG9IJsAo23Ba44.YOUd1 SPARC: pam_pwdb crypt_md5(): $1$xx$tcVZsr28tzKG890dmISsL/ GLIBC crypt(): $1$xx$ipOG9IJsAo23Ba44.YOUd1 My God! - pam_pwdb crypt_md5() makes different hashes depending on hardware platform. Finally, I've got that the problem lies in an incorrect detection of a byte order for the architecture. Please, look at pam-0.66/modules/pam_pwdb/md5.c:22, here is an attempt to understand the byte order by checking the presence of HIGHFIRST definition. I had simply replaced that string with #if __BYTE_ORDER != __BIG_ENDIAN and included an appropriate file endiand.h. Such changes I had applied to pam-0.66/modules/pam_radius/md5.c and pwdb-0.58/libpwdb/radius/md5.c too. After rebuilding and reinstalling packages everything works fine on both Ultra SPARC and Intel." ------- Additional Comments From jbj 07/16/99 11:49 ------- Matt, can you reply to this message with tar ball attached? TIA ------- Additional Comments From jbj 07/16/99 14:46 ------- *** This bug has been marked as a duplicate of 3777 *** ------- Additional Comments From jbj 07/16/99 14:47 ------- Matt, can you reply to this message with tar ball attached? TIA ------- Additional Comments From gewrgiou 07/22/99 09:44 ------- BUG #3898 is a duplicate of the same problem, i think the severity of this one is HIGH, imagine people with a few hundred md5 passwords in sparc.... Fixed in the current rawhide tree Why isn't there a new RPM to fix this problem? I built a new machine with all current RPMs yesterday. And applied all the upgraded RPMs and still ran into this problem. And resubmitted this same bug. Why isn't there a new RPM to fix this problem? I built a new machine with all current RPMs yesterday. And applied all the upgraded RPMs and still ran into this problem. And resubmitted this same bug. |