Red Hat Bugzilla – Bug 141393
cifs module only sends "Unicode" password
Last modified: 2015-01-04 17:13:21 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Description of problem:
Whenever the client sends only an "Unicode" ("NT"/"Case sensitive")
password, the Samba server will not be able to authenticate against
a password server in an NT domain.
One such client is the CIFS kernel module, which doesn't send the
less secure LanMan/ANSI/CaseSensitive password on purpose - some of
the code is in the source, but commented out. You can reproduce the
same behaviour with smbclient, by adding "client lanman auth = no"
Looking at network traffic, I see that whenever the client system
sends both passwords, the Samba server will successfully forward
the request to the password server. In the case of the smbfs
module, both passwords are identical binary strings of 24 bytes each.
If only the "Unicode" password gets sent, though, then Samba will
proceed to forward a request to the NT authentication server with
the right user and domain, but with the length of both passwords
set to zero.
Is it maybe just copying the "ANSI" password?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. set up Samba server in security = server mode
2. mount share with cifs (or smbfs with "client lanman auth = no")
Actual Results: Samba server tries to authenticate the user with an
Expected Results: Samba server should trie to authenticate using the
password it was
given and thus succeed.
I would have classified this as Severity: high, but it's not exactly
a case of "crashes, lots of data, severe memory leak".
Have you reported this upstream at bugzilla.samba.org ? Please do,
as the Samba team is likely better at debugging this than I.
Incidentally, why are you using "security = server" in the first
place. Page 36 of the Official Samba-3 HOWTO and Reference Guide
says "It is highly recommended not to use his feature.", and I can
only agree with that statement.
It turns out this is most likely a bug in cifs. And I was wrong, I
couldn't reproduce it with smbclient - there was an error mounting the
share, but for unrelated reasons.
The cifs module only sends the Unicode/CaseSensitive/NTLM response, on
the principle that the LM response encryption is very easy to crack.
It turns out that that's not exactly the way to avoid sending an LM
response. On an XP system, setting LMCompatibilityLevel to 2 (meaning
"no LM response is sent") results in the LM response being set to the
same value as the NTLM response. In other words, it's ugly, but smbd
is still "right" when expecting a non-null LM response.
I'm changing the component. Please reassign to the appropriate
developer if Bugzilla doesn't do it automatically. I have no idea who
that would be.
More details, with a patch:
Heh, that was a mid-air collision.
I already talked to Tridge and Steve French about it. Tridge suggested
waiting for Andrew Bartlett to return from vacation.
Looking at XP's behaviour, it looks like this is a scenario that is
not supposed to happen in the first place. I would still feel
uncomfortable with leaving it unhandled - no warnings whatsoever!
I suppose this should be fixed in cifsfs first, though.
As to using "security = server", there are cases in which it's
difficult to join a domain. Think of bureaucracy.
The cifs.ko part of the bug should be fixed in 2.6.10. There is no
mention of it in the (huge) CIFS 2.6.10 changelog, but, if you look
at connect.c, you should now see the response being sent in both
fields. I guess the resolution of this bug depends on the release of
a 2.6.10 kernel update, if there's going to be such a thing.
According to a few Samba developers, smbd is guilty as well. It
shouldn't fail miserably like that when it receives a request with
only one password field set. I tried against a W2K server and it
handled such a request without problems. Andrew Bartlett said he'll
look into rewriting the code at fault.