RE: FW: encrypt passwords = no, security=user, samba 3.0a22
Here you go. Enjoy :) N. -- Nir Soffer -=- Exanet Inc. -=- http://www.evilpuppy.org "Father, why are all the children weeping? / They are merely crying son O, are they merely crying, father? / Yes, true weeping is yet to come" -- Nick Cave and the Bad Seeds, The Weeping Song > -Original Message- > From: Richard Sharpe [mailto:[EMAIL PROTECTED] > Sent: Saturday, March 15, 2003 2:30 AM > To: Nir Soffer > Cc: Christopher R. Hertel; [EMAIL PROTECTED] > Subject: RE: FW: encrypt passwords = no, security=user, samba 3.0a22 > > > On Tue, 11 Mar 2003, Nir Soffer wrote: > > > > > FWIW turning off unicode with unicode=no helps somewhat, and both > > ethereal and Samba parse the session request correctly: > > Hmmm, I fixed a problem in Ethereal around Unicode handling > last week at > Connectathon. I would be very interested in a trace that shows the > problem. > > Regards > - > Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, > sharpe[at]ethereal.com, http://www.richardsharpe.com > > badpass.cap Description: badpass.cap aftersp.cap Description: aftersp.cap nounicode.cap Description: nounicode.cap
Re: FW: encrypt passwords = no, security=user, samba 3.0a22
Richard Sharpe wrote: > > On Tue, 11 Mar 2003, Nir Soffer wrote: > > > > > FWIW turning off unicode with unicode=no helps somewhat, and both > > ethereal and Samba parse the session request correctly: > > Hmmm, I fixed a problem in Ethereal around Unicode handling last week at > Connectathon. I would be very interested in a trace that shows the > problem. Run Samba 3.0 with plaintext passwords. Then log on from both a W2K and a W/XP system. Make sure the Windows clients have been registry-hacked to allow plaintext. Piece of cake. I'm pretty sure I've sent you a capture on this before. I also sent one that showed that WindowsNT4SP3 adds extra nul bytes following some Unicode strings, and that Window2000 will sometime drop one nul byte at the end of the PrimaryDomain field (such that the PrimaryDomain Unicode string isn't properly terminated). See also the !Alert box in section 2.7.2 of my book. ;l file:///home/crh/work/docs/cifsdocs/SMB.html#SMB.7.2 Chris -)- -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
RE: FW: encrypt passwords = no, security=user, samba 3.0a22
On Tue, 11 Mar 2003, Nir Soffer wrote: > > FWIW turning off unicode with unicode=no helps somewhat, and both > ethereal and Samba parse the session request correctly: Hmmm, I fixed a problem in Ethereal around Unicode handling last week at Connectathon. I would be very interested in a trace that shows the problem. Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
Re: FW: encrypt passwords = no, security=user, samba 3.0a22
Nir Soffer wrote: : > FWIW turning off unicode with unicode=no helps somewhat, and both ethereal and Samba > parse the session request correctly: > > [2003/03/11 20:11:30, 3] smbd/sesssetup.c:reply_sesssetup_and_X(732) > Domain=[CACOMISTLE] NativeOS=[Windows 2000 2195] NativeLanMan=[Windows > 2000 5 .0] > [2003/03/11 20:11:30, 3] smbd/sesssetup.c:reply_sesssetup_and_X(742) > sesssetupX:[EMAIL PROTECTED] > > So it seems you hit the mark. Now it's time to figure out how to fix it > :) It's something I would do if I had time right now, but I am trying to finish up several projects all at once. > Thanks again! We aims to please. :) Chris -)- -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
RE: FW: encrypt passwords = no, security=user, samba 3.0a22
> Nir Soffer wrote: > : > : > > It seems to me that a more correct fix would be, in the > case of encrypt > > passwords = no, to request a normal password and not a > UNICODE one. Is > > this even possible in the protocol? (e.g - request > non-unicode passwords, > > but still support non-unicode filenames?) > > Unicode is either ON or OFF. If Unicode is negotiated, then > the Windows > clients will try to send a Unicode password. > > > This is definitely broken now if this the case, regardless > where the bug > > is... > > There are bugs in the Windows clients, clearly, but I think > that we can work > around them. I also think that smbclient needs to be tested > in this regard. FWIW turning off unicode with unicode=no helps somewhat, and both ethereal and Samba parse the session request correctly: [2003/03/11 20:11:30, 3] smbd/sesssetup.c:reply_sesssetup_and_X(732) Domain=[CACOMISTLE] NativeOS=[Windows 2000 2195] NativeLanMan=[Windows 2000 5 .0] [2003/03/11 20:11:30, 3] smbd/sesssetup.c:reply_sesssetup_and_X(742) sesssetupX:[EMAIL PROTECTED] So it seems you hit the mark. Now it's time to figure out how to fix it :) Thanks again! Nir. -- Nir Soffer -=- Software Engineer, Exanet Inc. -=- "The poor little kittens; They lost their mittens; And now you all must die. Mew, Mew, Mew, Mew, And now you all must die." www.sluggy.com, 24/10/02
Re: FW: encrypt passwords = no, security=user, samba 3.0a22
Nir Soffer wrote: : : > It seems to me that a more correct fix would be, in the case of encrypt > passwords = no, to request a normal password and not a UNICODE one. Is > this even possible in the protocol? (e.g - request non-unicode passwords, > but still support non-unicode filenames?) Unicode is either ON or OFF. If Unicode is negotiated, then the Windows clients will try to send a Unicode password. > This is definitely broken now if this the case, regardless where the bug > is... There are bugs in the Windows clients, clearly, but I think that we can work around them. I also think that smbclient needs to be tested in this regard. Chris -)- PS. It would also be nice (hint to others on this list) if Ethereal were patched to read these messed-up packets correctly. :) -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
RE: FW: encrypt passwords = no, security=user, samba 3.0a22
> Nir Soffer wrote: > > > > Something our QA department stumbled on: > > > > I try to log on to my Samba 3.0a22 installation (make, make > install, the > > usual shebang). The client name is CACOMISTLE (not the > NativeOS), the > > user name is nirs, (not the domain). > > Any ideas or thoughts, or are we doing something incredibly stupid? > > At a guess, you are using plaintext passwords with Unicode. > If my guess is > correct (a simple capture of the SMB SESSION SETUP ANDX > exchange would prove > it) then read on... > > I do not know how to convince a Windows *server* to request plaintext > passwords. As you are probably aware, it is easy to get > Samba to request > plaintext if that's really what you want to do. > > What that means is that the combination of Unicode and > plaintext passwords > is unusual. I have seen that W2K and W/XP clients will send Unicode > plaintext passwords if Samba requests it. Unfortunately, > they get the field > values wrong--in different ways--and it breaks the existing parsing in > Samba. > [ snip wonderful explanation ] > The Windows systems that I've been able to check do not send Plaintext > Unicode passwords correctly. My *guess* is that Microsoft > never tested this > because their servers don't set up the situation that would > require testing. > > I believe that Samba can compensate, but I have not had time > to look at the > code (let alone fix it). It should be an easy fix. Eg.: > > if( Unicode Password begins with 0x00 ) > skip a byte > if( Unicode Password does not end in 0x ) > Add two to the password length before processing > > Someone care to look into providing a patch? It seems to me that a more correct fix would be, in the case of encrypt passwords = no, to request a normal password and not a UNICODE one. Is this even possible in the protocol? (e.g - request non-unicode passwords, but still support non-unicode filenames?) This is definitely broken now if this the case, regardless where the bug is... Nir. -- Nir Soffer -=- Software Engineer, Exanet Inc. -=- "The poor little kittens; They lost their mittens; And now you all must die. Mew, Mew, Mew, Mew, And now you all must die." www.sluggy.com, 24/10/02
Re: FW: encrypt passwords = no, security=user, samba 3.0a22
Nir Soffer wrote: > > Something our QA department stumbled on: > > I try to log on to my Samba 3.0a22 installation (make, make install, the > usual shebang). The client name is CACOMISTLE (not the NativeOS), the > user name is nirs, (not the domain). > Any ideas or thoughts, or are we doing something incredibly stupid? At a guess, you are using plaintext passwords with Unicode. If my guess is correct (a simple capture of the SMB SESSION SETUP ANDX exchange would prove it) then read on... I do not know how to convince a Windows *server* to request plaintext passwords. As you are probably aware, it is easy to get Samba to request plaintext if that's really what you want to do. What that means is that the combination of Unicode and plaintext passwords is unusual. I have seen that W2K and W/XP clients will send Unicode plaintext passwords if Samba requests it. Unfortunately, they get the field values wrong--in different ways--and it breaks the existing parsing in Samba. I am making a lot of assumptions about your setup, and what I am describing may not be the actual problem (as aways, a capture would prove it), but here is what I have seen (thanks to others on this list for supplying packet captures): - With plaintext ANSI passwords (OEM eight-bit character set (extended ASCII)) the terminating nul byte is counted when indicating the password length. So, with ANSI passwords, a NULL password has a length of 1. - When Unicode plaintext passwords are requested by the server (something I've only seen Samba do), Windows2000 and WindowsXP will give the ANSI password length as zero (0), but... + WindowsXP *still includes the single nul terminating byte for the ANSI password*. That has the effect (as seen in Ethereal) of shifting the Unicode password string off by one. Eg.: ANSI Password Length: 0 Unicode Password Length: 16 Reserved: Capabilities: 0x00d4 Byte Count (BCC): 143 Unicode Password: 007700650061007A006C00650073 Account: phrep Primary Domain: WINXP Native OS: Windows 2002 2600 Service Pack 1 Native LAN Manager: Windows 2002 5.1 The correct Unicode password should be 7700650061007A006C0065007300 Ethereal (smartly) skips the extra nul byte preceeding the username (which is "phrep"). Note that the password length is given as 16 bytes, which includes the two nul bytes required to termintate the string (or it would, if the Unicode string alignment were correct). + Windows 2000 behaves differently (this looks more like what you're seeing). W2K also sets the ANSI Password Length to zero (0), but it doesn't add the nul byte, so the Unicode password is aligned correctly. Unfortunately, W2K forgets to count the terminating nul bytes in the Unicode Password Length: ANSI Password Length: 0 Unicode Password Length: 12 Reserved: Capabilities: 0x00d4 Byte Count (BCC): 109 Unicode Password: 67006F006F00620065007200 Account: Primary Domain: crh Native OS: WIGGLY Native LAN Manager: Windows 2000 2195 Extra byte parameters The Unicode Password Length should be 14 to include the two nul bytes, but since the length is given as 12 Ethereal sees the Account field as being empty and all of the remaining strings are shifted down. (That is, in this capture Account is "crh", Primary Domain is "WIGGLY", etc.) So, there you have it. The Windows systems that I've been able to check do not send Plaintext Unicode passwords correctly. My *guess* is that Microsoft never tested this because their servers don't set up the situation that would require testing. I believe that Samba can compensate, but I have not had time to look at the code (let alone fix it). It should be an easy fix. Eg.: if( Unicode Password begins with 0x00 ) skip a byte if( Unicode Password does not end in 0x ) Add two to the password length before processing Someone care to look into providing a patch? Chris -)- -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
