Bug 1011621 - Unable to mount plain text password Samba shares
Unable to mount plain text password Samba shares
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
19
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Sachin Prabhu
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-24 12:18 EDT by Panos Kavalagios
Modified: 2013-11-12 21:14 EST (History)
10 users (show)

See Also:
Fixed In Version: kernel-3.11.7-100.fc18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-10 02:56:16 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Panos Kavalagios 2013-09-24 12:18:49 EDT
Description of problem: Mount is failing for a samba share.


Version-Release number of selected component (if applicable): cifs-utils-6.1-3.fc19.x86_64


How reproducible: Mount a plain text samba share with the following option:
echo '0x30' > /proc/fs/cifs/SecurityFlags


Steps to Reproduce:
1. Use mount command
2.
3.

Actual results: The mount fails with the following explaination:

mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

and dmesg output:

CIFS VFS: Unable to select appropriate authentication method!
CIFS VFS: Send error in SessSetup = -22
CIFS VFS: cifs_mount failed w/return code = -22



Expected results: The mount point should have been mounted as used in the past.


Additional info: The following options are used in rc.local:

# Load CIFS module
modprobe cifs
# Disable Unix extensions for link dereferencing at server side
echo 0 > /proc/fs/cifs/LinuxExtensionsEnabled
# Set lower security for old samba versions
echo '0x30' > /proc/fs/cifs/SecurityFlags
Comment 1 Panos Kavalagios 2013-09-26 03:50:28 EDT
Please to re-assign the issue to kernel folks.

It works fine with previous kernel kernel-3.10.11-200.fc19.x86_64. It does not work on the latest kernel-3.11.1-200.fc19.x86_64. I have booted 3.10.11 and the share was successfully mounted.

The evil 3.11.1 kernel has deprived of our samba shares.
Comment 2 Panos Kavalagios 2013-09-26 07:34:35 EDT
A not so recommended temporary workaround:

# yum remove kernel-3.11.1-200.fc19.x86_64
# yum remove kernel-devel-3.11.1-200.fc19.x86_64
# grub2-mkconfig -o /boot/grub2/grub.cfg
# grub2-install /dev/sda
# yum install yum-plugin-versionlock.noarch
# yum versionlock add kernel-3.10.11-200.fc19
# yum versionlock add kernel-devel-3.10.11-200.fc19.x86_64
# yum check-update
<empty>
Comment 3 Jeff Layton 2013-09-26 10:32:00 EDT
Probably fallout from the auth overhaul and cleanup that went into 3.11. We'll likely need to add some special-casing to allow the client to use plaintext passwords when the server doesn't send a legacy NEGOTIATE response.

The best thing UI-wise, IMO would be to add a sec=plain mount option instead of having to do this weirdo fiddling with the SecurityFlags, but I'm not sure Steve will accept that solution.
Comment 4 Steven French 2013-09-26 17:36:47 EDT
Even though Samba server tries to discourage you from plaintext (for good reason), and other servers may not even support plaintext at all, it looks like plaintext will still work to Samba with current kernels.  

On 3.12-rc2 (and 3.11) I was able to send a plaintext password as follows:

On server:
a) smb.conf "encrypt passwords = no" (since the kernel client will only send plaintext if the server says that password encryption is not supported - ie only will use plaintext if it is forced too due to server not supporting encryption)
b) smb.conf "max protocols = LANMAN2" (since the client only does plaintext with old lanman dialect)

On client:
c) echo 0x30 > /proc/fs/cifs/SecurityFlags (to allow client to send plaintext)
d) mount with cifs (not with smb2, which uses ntlmssp which does not support plaintext)

With those steps I see the client sending a plaintext password to the server
Comment 5 Jeff Layton 2013-09-26 17:58:34 EDT
Right, that should be a reasonable workaround iff you have control over the server. What's needed at this point is a way to force the client to use LANMAN/plaintext auth even when we don't get a legacy NEGOTIATE response.

So, what's probably needed is to patch select_sectype() to handle this situation properly. The _clearest_ way to do it from a UI standpoint would be to allow someone to specify sec=plain or something as a mount option and then handle that in the switch block for each negprot response type.

Alternately (or maybe in addition to that) you could have select_sectype() check for certain values of global_secflags and force LANMAN + plaintext auth.
Comment 6 Steven French 2013-09-26 18:07:09 EDT
Presumably you could specify sec=lanman on mount to force the client to negotiate lanman? So wouldn't this work without the smb.conf max protocols set if you specify "sec=lanman" ... or if we want to pass "sec=ntlm" (not ntlmssp) to force us to use non-NTLMSSP ie original nt style session setup request format, but to allow "sec=ntlm" to send plaintext we would need the equivalent line to this (which is in calc_lanman_hash) but in the ntlm hash generation

	if (!encrypt && global_secflags & CIFSSEC_MAY_PLNTXT) {
		memcpy(lnm_session_key, password_with_pad,
			CIFS_ENCPWD_SIZE);

the value of encrypt is set based on the server returning capabilities on negotiate that do not include encryption (ie setting smb.conf password encrypt = no)
Comment 7 Sachin Prabhu 2013-09-27 04:54:04 EDT
My notes about this issue:

Change due to commit
3f618223dc0bdcbc8d510350e78ee2195ff93768

Before this patch was introduced, the security method used was set in the negotiation phase ie. set by the first mount of a share on the server. Subsequently new sessions on that server re-used the authentication information from the first session.

As a result of the patch, we now use the server->negflavor field to the flavour negotiated. The flavour is negotiated based on the data returned in the negotiate response and can be deduced simply by looking at the WordCount of the negotiate response.

http://msdn.microsoft.com/en-us/library/ee441946.aspx
--
If the server has selected any dialect from LAN Manager 1.0 through LAN Manager 2.1, WordCount MUST be 0x0D. See [XOPEN-SMB] for a specification of the LAN Manager dialects other than LAN Manager 2.1. [SMB-LM21] provides documentation on the extensions to the LAN Manager 2.0 dialect that define the LAN Manager 2.1 dialect.

If the server has selected the NT LAN Manager dialect, then WordCount MUST be 0x11.
--

Accordingly, we set the negotiate flavour in 

int
CIFSSMBNegotiate(const unsigned int xid, struct cifs_ses *ses)
{
..
//If word count is 13, the negotiate response suggests that the server supports LANMAN authentication flavour.
        } else if (pSMBr->hdr.WordCount == 13) {
                server->negflavor = CIFS_NEGFLAVOR_LANMAN;
..
//Else in case wordcount is set to 17. ie. NTLM dialect
        //Check the encryption key length set. This according to the doc
        //linked above, is set to 0 or 8.
        //First case is in case server supports challenge response authentication. 
        if (pSMBr->EncryptionKeyLength == CIFS_CRYPTO_KEY_SIZE) {
                server->negflavor = CIFS_NEGFLAVOR_UNENCAP;
                memcpy(ses->server->cryptkey, pSMBr->u.EncryptionKey,
                       CIFS_CRYPTO_KEY_SIZE);
        //Or check to see if extended security is enabled in which case we use 
        //Extended ie. encapsulated encryption.
        } else if ((pSMBr->hdr.Flags2 & SMBFLG2_EXT_SEC ||
                        server->capabilities & CAP_EXTENDED_SECURITY) &&
                                (pSMBr->EncryptionKeyLength == 0)) {
                server->negflavor = CIFS_NEGFLAVOR_EXTENDED;
                rc = decode_ext_sec_blob(ses, pSMBr);
        //Check to see if the server supports password encryption.
        } else if (server->sec_mode & SECMODE_PW_ENCRYPT) {
                rc = -EIO; /* no crypt key only if plain text pwd */
        //default is to use unencapsulated NTLM/NTLMv2 authentication.
        } else {
                server->negflavor = CIFS_NEGFLAVOR_UNENCAP;
                server->capabilities &= ~CAP_EXTENDED_SECURITY;
        }
}

We get into trouble because we do not expect to do plain text password authentication when the Negotiate protocol select a NT Lan Manager dialect ie. CIFS_NEGFLAVOR_UNENCAP or CIFS_NEGFLAVOR_EXTENDED.

//We then set the authentication method based on the mount option passed for mounting this particular share.
int
CIFS_SessSetup(const unsigned int xid, struct cifs_ses *ses,
               const struct nls_table *nls_cp)
{
..
        type = select_sectype(ses->server, ses->sectype);
..
        if (type == Unspecified) {
                cifs_dbg(VFS,
                        "Unable to select appropriate authentication method!");
                return -EINVAL;
        }
..
}

enum securityEnum
select_sectype(struct TCP_Server_Info *server, enum securityEnum requested)
{
        switch (server->negflavor) {
        case CIFS_NEGFLAVOR_EXTENDED:
                switch (requested) {
                case Kerberos:
                case RawNTLMSSP:
                        return requested;
                case Unspecified:
                        if (server->sec_ntlmssp &&
                            (global_secflags & CIFSSEC_MAY_NTLMSSP))
                                return RawNTLMSSP;
                        if ((server->sec_kerberos || server->sec_mskerberos) &&
                            (global_secflags & CIFSSEC_MAY_KRB5))
                                return Kerberos;
                        /* Fallthrough */
                default:
                        return Unspecified;
                }
        case CIFS_NEGFLAVOR_UNENCAP:
                switch (requested) {
                case NTLM:
                case NTLMv2:
                        return requested;
                case Unspecified:
                        if (global_secflags & CIFSSEC_MAY_NTLMV2)
                                return NTLMv2;
                        if (global_secflags & CIFSSEC_MAY_NTLM)
                                return NTLM;
                        /* Fallthrough */
                default:
                        return Unspecified;
                }
        case CIFS_NEGFLAVOR_LANMAN:
                switch (requested) {
                case LANMAN:
                        return requested;
                case Unspecified:
                        if (global_secflags & CIFSSEC_MAY_LANMAN)
                                return LANMAN;
                        /* Fallthrough */
                default:
                        return Unspecified;
                }
        default:
                return Unspecified;
        }
}

In this particular case, the server sets a NT LanManager Dialect which sets the negflaour to CIFS_NEGFLAVOR_EXTENDED or to CIFS_NEGFLAVOR_UNENCAP(set depending on encryption key returned in the negotiate response) which prevents the user from using plain text authentication which requires LANMAN authentication.
Comment 8 Sachin Prabhu 2013-09-27 13:41:18 EDT
http://thread.gmane.org/gmane.linux.kernel.cifs/8881
Comment 9 Panos Kavalagios 2013-10-29 05:23:37 EDT
It is not clear to me. Was that fix included in a specific kernel version or it is still under evaluation?
Comment 10 Sachin Prabhu 2013-10-29 06:23:06 EDT
The patch required to fix this issue has been included in the upstream kernel
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/cifs?id=dde2356c8466298bd77fa699e0ea296372eed47b

We now wait for the patches to be pulled into the Fedora kernel.
Comment 11 Josh Boyer 2013-10-29 13:43:27 EDT
(In reply to Sachin Prabhu from comment #10)
> The patch required to fix this issue has been included in the upstream kernel
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/
> cifs?id=dde2356c8466298bd77fa699e0ea296372eed47b
> 
> We now wait for the patches to be pulled into the Fedora kernel.

Shouldn't that be CC'd to stable?  It's a regression in 3.11 and the patch is relatively small.  It's already in 3.12-rc6, so getting it into 3.11.7 should not be difficult.
Comment 12 Josh Boyer 2013-10-29 14:24:24 EDT
Added to Fedora git.  Should likely still be pushed into upstream stable.
Comment 13 Fedora Update System 2013-11-02 15:15:14 EDT
kernel-3.11.6-302.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/kernel-3.11.6-302.fc20
Comment 14 Fedora Update System 2013-11-02 15:20:33 EDT
kernel-3.11.6-201.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/kernel-3.11.6-201.fc19
Comment 15 Fedora Update System 2013-11-02 15:24:06 EDT
kernel-3.11.6-101.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/kernel-3.11.6-101.fc18
Comment 16 Fedora Update System 2013-11-03 00:35:04 EDT
Package kernel-3.11.6-101.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.11.6-101.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-20545/kernel-3.11.6-101.fc18
then log in and leave karma (feedback).
Comment 17 Panos Kavalagios 2013-11-04 03:21:15 EST
It works fine:

# yum versionlock clear
Loaded plugins: auto-update-debuginfo, fastestmirror, refresh-packagekit,
              : versionlock
versionlock cleared

# yum --enablerepo=updates-testing update kernel\*
...
================================================================================
 Package            Arch       Version                Repository           Size
================================================================================
Installing:
 kernel             x86_64     3.11.6-201.fc19        updates-testing      30 M
 kernel-devel       x86_64     3.11.6-201.fc19        updates-testing     8.4 M
Updating:
 kernel-headers     x86_64     3.11.6-201.fc19        updates-testing     883 k
...

$ uname -a
Linux bb229 3.11.6-201.fc19.x86_64 #1 SMP Sat Nov 2 14:09:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

I've tested read/write operations on the share and no issue was observed. I've added +1 karma. Many thanks for the quick resolution!
Comment 18 Fedora Update System 2013-11-04 15:17:40 EST
kernel-3.11.7-300.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/kernel-3.11.7-300.fc20
Comment 19 Fedora Update System 2013-11-04 15:19:48 EST
kernel-3.11.7-100.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/kernel-3.11.7-100.fc18
Comment 20 Fedora Update System 2013-11-04 21:58:00 EST
kernel-3.11.6-201.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 21 Fedora Update System 2013-11-05 15:04:20 EST
Package kernel-3.11.7-300.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.11.7-300.fc20'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-20705/kernel-3.11.7-300.fc20
then log in and leave karma (feedback).
Comment 22 Fedora Update System 2013-11-10 02:56:16 EST
kernel-3.11.7-300.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 23 Fedora Update System 2013-11-12 21:14:31 EST
kernel-3.11.7-100.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

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