incorrect password length - bug?

Pierre Belanger pbelang1 at oss.cantel.rogers.com
Wed Jan 29 20:40:19 GMT 2003


Jerry,

Gerald (Jerry) Carter wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Wed, 29 Jan 2003, Pierre Belanger wrote:
> 
> 
>>Reference:
>>
>>http://lists.samba.org/pipermail/samba-technical/2001-August/015596.html
>>
>>I was playing around with smbpasswd last night. I first thought
>>something committed in CVS broke something, I checked all changes
>>made since the past 1-2 days and found nothing :(  I than
>>downgraded to an old copie of samba I kept and was quite surprised
>>to see I was still having the same behavior!
>>
>>Here we go. Using smbpasswd -r localhost -U <username>
>>if you type in the wrong current (old) password, smbd
>>reports:
>>
>>[2003/01/29 14:13:05, 0] smbd/chgpasswd.c:check_oem_password(817)
>>check_oem_password: incorrect password length (1980737076).
>>
>>This value comes from new_pw_len = IVAL(lmdata, 512) in
>>chgpasswd.c . I tried hard to find the reason, even with
>>debug level @ 9, I caaaaan't :(
> 
> 
> The passeord change is done by sending a large buffer and encrypting it 
> with the old password.  The first 512 bytes a random junk and the 
> clear text of the new password is tagged on.  Since you used a wrong old 
> password, the buffer cannot be decryptesd correctly when smbd uses the 
> correct password.  Thus the length field is invalid.  Make sense?
> 
It's encrypted, no wonder why I did not understand nothing ;-)
Yes, it all makes much more sense now.

> I could be more specific, but I would need to look back at that code 
> again to refresh my memory.
> 
If the calculated new_pw_length is incorrect, doesn't this always
mean that the supplied password is wrong? Can't we log something
like: "old supplied password not good" or "bad pass length (%d) -
old supplied passwd wrong". I might be missing something *else*.

I haven't checked all layers in smbd, I guess we do check somewhere
the length of "lmdata" in case it's too short way before we get to
IVAL(lmdata, 512)... so IVAL doesn't try to "read in the memory"
from somewhere it shouldn't (it's not a buffer overflow just can't
remember the right English expression!). I'll learn by myself all
the "Samba internal layers" one day... no need to comment on this.

Thanx for your time,
Pierre B.



More information about the samba-technical mailing list