[linux-cifs-client] Rudi's question about smbd/smbfs/cifsvfs

[Christopher R. Hertel]

Steve, et. al.,

I should mention that Rudi's a friend of mine.  We worked together at
Amiga for a while, while he was still in Napoli.  He's now in Minnesota,
about 1.5 hours south of me (1hr if my wife is driving).
He asked me to take a look at this...

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

So what's happening here is that smbfs is putting the response (it's 
neither a hash nor a password) into *both* fields.  I wonder why Urban (or 
whomever) did that...  Read on...

> The result is that smbd sends a request with an user and a password.

By which, I believe, Rudi means that smbd--running in security=server 
(aka. passthrough) mode is finding the 24-byte response and passing it 
through to the server.

> The cifs module sends just one password, and it results in
> smbd sending a request with the right user, but *NO PASSWORD*.

Rudi: Which password field is filled in?  The first or the second?  If 
      it's the first, then cifsvfs is placing the NTLM response into the
      wrong field.  If it's the second, then smbd is looking in the wrong
      place for the response.

      Which version of Samba are you running?

      What other authentication parameters are set in the smb.conf on that 
      server?

If I understand the other messages correctly, the goal here is to have
clients send the NTLM response only.  If the CIFS VFS is placing the NTLM
response into the correct field (which I assume is happening, since the
behavior of SMBFS is an obvious work-around) then the problem is that smbd 
is looking in the wrong place for the response.  That being the case, it 
could be:
  - an older version of smbd, and newer versions have this fixed.
  - a configuration error, some parameter telling smbd to look for the LM 
    response.

:
:
:

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

I'll want to see the trace.  If this is a bug in the smbd you're using, 
who knows what length it's declaring?

> Looking at the function's docs, it says:
>
>    @param pass *either* cleartext password (passlen !=24) or LM
> response.

Right.  That first password field was originally used for cleartext 
passwords.  In theory, you could have a 24byte cleartext password... I 
think.

This is also the field used for the LM or LMv2 Response (24-byte values).

>    @param ntpass NT response, implies ntpasslen >=24, implies pass is 
>  not clear

I've managed to trick smbclient into sending plaintext Unicode passwords.  
I did this work a few years ago, and I don't remember all of the details.  
I believe that the folks who code Windows never tested Unicode plaintext.

Anyway, Unicode plaintext would go into this second field.  If 
challenge/response is in use, this field will contain the NTLM response 
(24 bytes) or the more complex NTLMv2 response (which is generally much 
larger than 24 bytes).

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

If NTLM is enabled but LM is disabled, you will see the first field empty 
and the second field full (24 byte NTLM response).

I don't know if it's possible to send NTLMv2 without also sending the LMv2 
response.

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

My guess is that you're suggestion is correct:  SMBFS is placing the NTLM
response into both fields to work around a bug.

I'd need to see traces and know which Samba version you're running.

Chris -)-----

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org