Hide Forgot
Created attachment 493035 [details] unix_chkpwd patched to log username and password on fail and success Description of problem: SMB client sends password "XYZ" to access a Samba share, however, somewhere the password is changed from "XYZ" to the literal character "c". Unless password is actually "c", the client gets the error "NT_STATUS_WRONG_PASSWORD" How reproducible: Every time Steps to Reproduce: 1. Create the directory to be shared mkdir -m 1777 -p /srv/samba/tmp chcon -R -t samba_share_t /srv/samba 2. Use this Samba configuration (/etc/samba/smb.conf): [global] workgroup = EXAMPLE security = share encrypt passwords = no client plaintext auth = yes client lanman auth = yes log level = 0 passdb:10 auth:10 [tmp] path = /srv/samba/tmp writeable = yes guest ok = no username = tmpshare only user = yes 3. Create the "tmpshare" Linux user to hold the password for this share: useradd -c "dummy account for Samba [tmp]" -M -s /bin/bash tmpshare passwd tmpshare # set the password to 'foofoo' 4. Start Samba and attempt to connect to the share: /etc/init.d/smb start smbclient //localhost/tmp -U jdoe Enter jdoe's password: foofoo Notice the "NT_STATUS_WRONG_PASSWORD" error In the /var/log/secure, notice: Apr 18 14:20:39 station2 unix_chkpwd[19207]: password check failed for user (tmpshare) 5. Reset the password to "c" and try again. Notice that it works: passwd tmpshare # set the password to 'c' smbclient //localhost/tmp -U jdoe In order to troubleshoot this further I installed a modified "/sbin/unix_chkpwd" binary. I patched it to log both the username and password on success and failure. This is how I discovered the password was being munged to 'c'. I've attached the patch to this bug. Here is an example of the new debug log output (when the password is set to 'foofoo': Apr 18 14:03:26 station2 unix_chkpwd[18946]: password check failed for user (tmpshare), pass (c) Somewhere along the line, the supplied password is being changed to 'c'. I reproduced this bug on RHEL6 as well.
security = share and encrypt password = no are deprecated options and most clients can't really work with them anyways. CAn you change your configuration to not use them unencrypted passwords and use security = user + map to guest to let people access your shares ?
The configuration is used as part of a Linux training course (very popular, used by 10s of thousands of students over the years). They start with a simple Samba configuration and over 7 lab tasks build up to a very complex Samba configuration. We found this bug in validating the first task on RHEL6/Fedora 14. This seems pretty serious, with significant security implications, since "security = share" is not removed, only deprecated (a Google search shows lots of people still using it in 2011 for some odd reason) I figure it is worth fixing. Especially since, effectively there is a "back door" password of "c" no matter what the password actually is.
I am not saying we are not going to investigate this, just that it is lower priority as it is a configuration we strongly discourage. But, really, if you are teaching this in courses *please* stop doing it (I am asking this as a samba upstream too), security = share and no encryption are things you really do not want to teach any more, they are not usable in practice with any supported windows client anyway.
(In reply to comment #3) > I am not saying we are not going to investigate this, just that it is lower > priority as it is a configuration we strongly discourage. Understood > But, really, if you are teaching this in courses *please* stop doing it (I am > asking this as a samba upstream too), security = share and no encryption are > things you really do not want to teach any more, they are not usable in > practice with any supported windows client anyway. We don't recommend "security = share" in our course. It is the first step in the multi-task Samba lab we have. Regarding encryption, we also encourage it. In fact the lab task has the students do packet captures before and after enabling encryption and then using wireshark to analyze the captures to see the difference. We also teach the students that the encrypted strings are plain text equivalents. In task 2, we DO use "security = user" plus "map to guest", then in tasks 3 through 7 we go into increasingly more complicated configurations. Don't worry, students taking the class will be fully informed -- I don't expect any of them to be deploying "security = user", in fact they might be migrating off of such configurations.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping