Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 141393 - cifs module only sends "Unicode" password
cifs module only sends "Unicode" password
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-11-30 16:42 EST by Rudi Chiarito
Modified: 2015-01-04 17:13 EST (History)
1 user (show)

See Also:
Fixed In Version: 2.6.10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-15 10:50:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Rudi Chiarito 2004-11-30 16:42:12 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041109 Firefox/1.0

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"
to smb.conf.

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):

How reproducible:

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
empty password

Expected Results:  Samba server should trie to authenticate using the
password it was
given and thus succeed.

Additional info:

I would have classified this as Severity: high, but it's not exactly
a case of "crashes, lots of data, severe memory leak".
Comment 1 Jay Fenlason 2004-12-01 10:55:22 EST
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. 
Comment 2 Rudi Chiarito 2004-12-01 10:56:37 EST
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:

Comment 3 Rudi Chiarito 2004-12-01 11:03:45 EST
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.
Comment 4 Rudi Chiarito 2004-12-26 11:49:57 EST
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.

Note You need to log in before you can comment on or make changes to this bug.