Here I am forwading the second message from pam-list regarding MD5
problems ;
This one provides more details (as well as explains why I could not see
any problems trying MD5 on different machines, but all x86 based).
As far as I understand forwarded message the problem is with PAM and it is
going to be fixed.
Could anyone with access to an alpha Linux Box with RedHat 6.0 check that
MD5 hashes generated on x86 Linux boxes (with PAM from RedHat 5.2 or 6.0)
are accepted by the glibc-crypt based sample program I have sent to the
list a few days ago?
Please mail me privately is any help from my side is needed.
Best regards,
Wojtek
---------- Forwarded message ----------
Date: Thu, 17 Jun 1999 10:43:06 +0400
From: Savochkin Andrey Vladimirovich <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [Fwd: MD5 passwords]
Resent-Date: 17 Jun 1999 08:10:42 -0000
Resent-From: [EMAIL PROTECTED]
Resent-cc: recipient list not shown: ;
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
--
To unsubscribe: mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
