[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Fwd: MD5 passwords]



Savochkin Andrey Vladimirovich wrote:
> 
> Hi,
> 
> On Wed, Jun 16, 1999 at 07:49:23AM -0700, Andrew Morgan wrote:
> > Savochkin Andrey Vladimirovich wrote:
> > > that MD5 calculation code compiles with pam_pwdb module in a wrong way.
> > > The result is that hashes calculated big-endian systems are different from
> > > expected.
> > >
> > > Last weekend I tried to solve the problem but it appeared to be not so easy as
> > > it might.  In my experiments pam_pwdb module with the correct MD5 routines
> > > failed too because the dynamic linker resolved references to another instance
> > > of MD5 routines in libpwdb.  Version of libpwdb which I used
> > > compiled MD5 code in a wrong way too :-(
> >
> > Are you saying that
> >
> >  1. on bigendian systems the md5 sources in pam_pwdb compiles
> > incorrectly
> 
> Yes.  The present md5.c needs an external predefined symbol which specifies the
> endianess.   The symbol is HIGHFIRST - it is checked
> in the first dozen lines of the md5.c.  MD5 source in modules/pam_pwdb
> directory doesn't obtain the necessary definition.
> 
> >  2. pam_pwdb calls to md5 functions get linked with broken md5 code in
> > libpwdb
> 
> I don't know exactly how dynamic linker works.  In one of
> my experiments I linked pam_pwdb with md5.c compiled for big endian.
> The hashing result was wrong.  At a quick look it seemed that the dynamic
> linker used module md5.o from libpwdb (radius module) but I hadn't enough
> time to be sure.
> 
> >  3. both 1 and 2
> 
> Probably so.  I'm sure in #1 and I suspect #2.
> 
> >  4. something else
> >
> > Q. if 2 is part of the problem is this glibc (linker) specific?
> 
> I don't consider the linker behaviour as a problem.  But the linker choice
> which module to use may very well be glibc/version specific.
> 
> >
> > > So we need to fix Makefiles both in pam_pwdb and libpwdb and implement a
> > > backward compatibility hack somewhere.
> >
> > Yes, this seems like the right thing to do.
> >
> > > Some time ago I used MD5 code in a PAM client agent (was in libpam_client)
> > > with the necessary endianess checks.  But as far as I remember the checks
> > > weren't cross-compile safe.
> >
> > Anyone want to work out a patch?
> 
> I've got an idea how pam_pwdb module can be fixed.  On big endian
> architectures we may compile two MD5 modules (with different input byte order
> and different function names) and try them one after other on an
> authentication stage.
> Password changing part of the module should definitely generate the proper
> hash.
> 
> I haven't looked at libpwdb and don't know how easy to fix it (and whether it
> really compiles MD5 incorrectly or something else happened in my
> experiments).
> 

The md5 routines in rpm have the fix and should drop right into
libpwdb.

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj@redhat.com (jbj@jbj.org)
Chapel Hill, NC



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []