[linux-cifs-client] Re: CaseInsensitivePassword

Rudi Chiarito nutello at sweetness.com
Tue Nov 30 23:54:04 GMT 2004


On Mon, Nov 29, 2004 at 06:38:33PM -0600, Steven French wrote:
> So a theory is that your server's authentication configuration requires 
> weak lanman passwords to be enabled.   cifs vfs does not send the weak 
> lanman passwords, smbfs and most windows client do send it by default does 
> so it works.     My reaction is that the security problems of lanman hash 

I researched this some more and found something interesting. The smbfs
module does send both passwords, but they are identical - 24 byte long
binary strings. The result is that smbd sends a request with an user and
a password. The cifs module sends just one password, and it results in
smbd sending a request with the right user, but *NO PASSWORD*.

I haven't tried stepping through smbd at runtime, but I looked at
network traces and the smbd sources. The flow I have reconstructed is
this, with cifs:

1) I get this error

[2004/11/30 16:56:19, 1] auth/auth_server.c:check_smbserver_security(363)
  password server SERVER rejected the password

That's almost at the end of check_smbserver_security, in the code path
where plaintext is NOT available.

2) Looking at cli_session_setup() in libsmb/cliconnect.c, execution must
proceed until the very end of the function, because:
  a) the protocol is 8
  b) the user has been supplied
  c) server security is user level
  d) server supports challenge/response
  e) extended security is not supported

So, cli_session_setup_nt1 must be where things happen.

3) passlen should equal zero, because cifs only passes the NT password
(right?), so... smbd does "nothing - guest login", which is wrong.

Looking at the function's docs, it says:

   @param pass *either* cleartext password (passlen !=24) or LM
response.
   @param ntpass NT response, implies ntpasslen >=24, implies pass is
not clear

I am not sure if the above implies that when ntpass is not null, pass is
not null either.

I guess that's what is happening. I know now where things are going
wrong, but I am not sure if this should be fixed in cifs (by sending the
NTLM response in the LM response field like smbfs does - why does smbfs
do that?) or if smbd's cli_session_setup_nt1() should look also at
ntpasslen before deciding this is a guest login.

Comments?

-- 
Rudi


More information about the linux-cifs-client mailing list