Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
First Last Prev Next    This bug is not in your last search results.
Bug 3898 - md5 passwords are broken
md5 passwords are broken
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: pam (Show other bugs)
6.0
sparc Linux
high Severity high
: ---
: ---
Assigned To: Cristian Gafton
:
: 4074 (view as bug list)
Depends On:
Blocks:
  Show dependency tree / graph
 
Reported: 1999-07-04 23:45 EDT by Kostas Georgiou
Modified: 2008-05-01 11:37 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-08-23 21:00:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

  None (edit)
Description Kostas Georgiou 1999-07-04 23:45:02 EDT 
md5_crypt in pam/pwdb is broken in big endian machines
due to endianess problems, this breaks programs that
use glibc's crypt (sulogin for example).
NIS from/to little endian machines probably is broken
too, but i haven't check it.
There might be a security problem too if the bad passwords
are weaker than the correct md5 ones.

Upgrading to correct versions of the packages can be tricky
since the old passwords won't work anymore after the
upgrade.

Also pwdb and pam should be both updated at the same time,
since new passwords are created through the functions in
pwdb and checks are done through pam. (passwd is linked
against pwdb and pam and since libpwdb exports the md5
functions they are used instead of pams, this should be
fixed also at some point)

the patch against md5.c in pam is:
--- modules/pam_pwdb/md5.c      Fri Feb 12 09:39:10 1999
+++ modules/pam_pwdb/md5.c.bigendian    Sun Jul  4 18:23:34
1999
@@ -17,9 +17,10 @@
  */

 #include <string.h>
+#include <endian.h>
 #include "md5.h"

-#ifndef HIGHFIRST
+#if BYTE_ORDER == LITTLE_ENDIAN
 #define byteReverse(buf, len)  /* Nothing */
 #else
 void byteReverse(unsigned char *buf, unsigned longs);

similar fixes should go in modules/pam_radius/md5.c,
pwdb/libpwdb/radius/md5.c
(util-linux uses the same md5.c file in mcookie also).
Comment 1 Kostas Georgiou 1999-07-30 11:07:59 EDT 
i just found out that gdm has the same problem, same patch again
Comment 2 Anonymous 1999-08-02 12:37:59 EDT 
Ok. Fixed in my gdm2 devel tree.

Changed symbol names to avoid polluting PAM's name space as well.

-- Martin
Comment 3 Cristian Gafton 1999-08-02 19:53:59 EDT 
*** Bug 4074 has been marked as a duplicate of this bug. ***


This bug was reported by Andrew V. Nikulin
<andrew@elkatel.ru>

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@redhat.com  07/16/99 11:49 -------
Matt, can you reply to this message with tar ball attached? TIA

------- Additional Comments From jbj@redhat.com  07/16/99 14:46 -------


*** This bug has been marked as a duplicate of 3777 ***

------- Additional Comments From jbj@redhat.com  07/16/99 14:47 -------
Matt, can you reply to this message with tar ball attached? TIA

------- Additional Comments From gewrgiou@imbc.gr  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....
Comment 4 Cristian Gafton 1999-08-23 21:00:59 EDT 
Fixed in the current rawhide tree
Comment 5 jco 1999-08-30 10:40:59 EDT 
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.
Comment 6 jco 1999-08-30 23:25:59 EDT 
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.
Note You need to log in before you can comment on or make changes to this bug.
First Last Prev Next    This bug is not in your last search results.