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

Re: [Fwd: MD5 passwords]



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).

I have already planned a picnic for the weekend so I shall not be able to
make the patch in the nearest feature.  A weekend after if nobody else
volunteers :-)

Best wishes
					Andrey V.
					Savochkin



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