Description of problem: mount.cifs fails to correctly authenticate when using a credentials file. samba-3.0.37-CVE-2009-2948.patch causes the open_cred_file function to include the trailing newline in the authentication information. This is visible if you mount with the --verbose option. I think that either the strlcpy calls should be changed to rely on the length variable (as the original strncpy calls did) or the preceding for loops that read the values should set the last-read character to NULL (as the upstream 3.0.37 release does). Version-Release number of selected component (if applicable): samba-client-3.0.33-3.15 How reproducible: It fails consistently when using a credentials file. Mounts without a credentials file work, and the previous RPM works. Steps to Reproduce: 1. Create a credentials file with username, password, and domain. 2. mount -t cifs //server/share /mnt -o cred=/credentials.txt Actual results: Mount fails with NT_STATUS_LOGON_FAILURE. Expected results: Successful CIFS mount. Additional info: Bug ID 532094 for RHEL4 may describe the same problem.
I.m seeing this too. All backups (using cifs) failed last night.
I am seeing the same issue. This bug is reported for RHEL 4 as well at: https://bugzilla.redhat.com/show_bug.cgi?id=532094
Created attachment 367143 [details] patch -- fix up newlines in parsing routines This patchset fixes the issue.
I have rebuilt samba with the patch provided. The credential files are working once again.
When will this be available in an RHN bugfix package? This is affecting our critical production processes. Currently using AWK workaround from bugzilla #445623, but need a package that fixes permanently.
Is this also a problem with smbclient? I find passing the credentials with -A also fails, but passing with -U works fine.
(In reply to comment #10) > Is this also a problem with smbclient? I find passing the credentials with -A > also fails, but passing with -U works fine. No, that appears to work just fine here.
Does it work when running as root but authenticating as a different domain/user?
Dummy me, discovered had "user=" in credentials file instead of "username=".
The patch corrects the problem. Note that this problem will _ONLY_ be seen when attempting to mount shares on a Windows system. When attempting to repro with a Samba server, the problem does not occur.
Also wanted to take a moment to share a workaround found by one of our support engineers, in case an alternative workaround has not already been utilized. This way folks can get back up and running again while we await updated packages to be QA'd and released. To work around this bug, a credentials file is needed in which there is no newline character at the end of the password line. One way to accomplish this is: # printf "username=user1\npassword=secret" > /cred_file # mount.cifs //server.example.com/share /mnt -o credentials=/cred_file substituting the appropriate username for "user1" and password for "secret". The cred_file can be named and located anywhere that meets your security requirements. In most, if not all situations, the credentials file can be owned by root:root and have 640 permisions and still work properly.
Note that the above workaround seems to work only if you're using username and password. We also use domain, and it seems that whatever the second option in the file is, it will pull in the trailing newline for that. So: printf "username=ray5147\ndomain=esri.com\npassword=xxx" > \ /etc/auto.smb.credentials Results in the domain parameter being passed to mount.cifs with an embedded newline. If we use only two options (username and domain), it appears to work fine.
Also, it doesn't appear that /etc/auto.smb correctly handles a credentials file without a trailing newline correctly (or, to be accurate, smbclient -A does not). You'll need to do some one-off modifications of /etc/auto.smb if you're using a credential file there -- one version to work with mount.cifs and another to work with smbclient. At least until the fix is available or you patch manually :-)
Just to update/correct a previous post of mine, Engineering found in extended testing that this problem CAN occur with a Samba server hosting the CIFS share.
(In reply to comment #22) > Note that the above workaround seems to work only if you're using username and > password. We also use domain, and it seems that whatever the second option in > the file is, it will pull in the trailing newline for that. > > So: > > printf "username=ray5147\ndomain=esri.com\npassword=xxx" > \ > /etc/auto.smb.credentials > > Results in the domain parameter being passed to mount.cifs with an embedded > newline. If we use only two options (username and domain), it appears to work > fine. Another workaround is to add the "null" character at end of lines. The following should work with both smbclient and mount.cifs (at least it works for me) : printf "username=ray5147\0\ndomain=esri.com\0\npassword=xxx\0\n" > \ /etc/auto.smb.credentials
Aside from the work arounds, when can we expect this bug to be fixed, should be simple. I have many clients who are affected now.
(In reply to comment #26) > Another workaround is to add the "null" character at end of lines. The > following should work with both smbclient and mount.cifs (at least it works for > me) : > > printf "username=ray5147\0\ndomain=esri.com\0\npassword=xxx\0\n" > \ > /etc/auto.smb.credentials Hah, very cool. Thanks. (In reply to comment #27) > Aside from the work arounds, when can we expect this bug to be fixed, should be > simple. I have many clients who are affected now. I wouldn't hold your breath on an official fix coming out soon. Still QA to be done and such. I would however open an SR and request a hotfix if you're not comfortable with maintaining a patched version yourself or using one of the workarounds mentioned above. Just my $0.02.
Indeed. Red Hat customers with active support entitlements are encouraged to open a support request with Red Hat Global Support. The more customers we have with tickets filed against this bug, the better. --vince
Opened SR #1972386 if anyone wants to reference it in addition to this bz when they open theirs.
Seems like RH won't release a fix until the RHEL 5.5 release (info from a SR answer : #1971868 ).
There is a test package for RHEL4 at http://people.redhat.com/jpayne/361510/ Can we expect something similar for RHEL5? Thanks, Luc
As reported in comment #6, I have a patched version of samba for RHEL/CentOS-5. I have been running it on my machines and also offered it to the CentOS community. Help yourself if you would like to give it a try as an interim solution: http://centos.toracat.org/misc/testing/samba/
Opened S.R. 1966542 02-NOV-2009
We have a set of internal test packages for i386 and x86_64 builds which have been added to to jpayne's people page a few minutes ago at: http://people.redhat.com/jpayne/532153/
I am testing the package and had no success, still with the same problem, credential does not work, still working just putting username and password. Rodrigo Munhoz Ramos
Estou usando RHEL 4 AS, pacotes: system-config-samba-1.2.21-1 samba-3.0.33-0.18.el4_8jptest361510 samba-common-3.0.33-0.18.el4_8jptest361510 samba-client-3.0.33-0.18.el4_8jptest361510
Rodrigo, did you verify the packages were actually installed? I had to "--force" them, since for RHEL5 they are interpreted as an earlier version than the current RHN available packages. Be sure in yum or up2date that you have an exception so that RHN will not attempt to re-upgrade them again. Everyone: for RHEL5, these have apparently worked on my redundant system, I had to put exceptions on that system for "samba-*" to prevent overwrite by RHN. RedHat: Unless anyone has any issues in RHEL5, please promote to a bugfix RPM available on RHN so I can put in production on my primary systems affected by this.
All, problem resolved in RHEL 4 AS I upgraded my linux to update 8. follows before: Red Hat Enterprise Linux AS release 4 (Nahant) rpm -qa | grep samba system-config-samba-1.2.21-1 samba-3.0.33-0.18.el4_8jptest361510 samba-common-3.0.33-0.18.el4_8jptest361510 samba-client-3.0.33-0.18.el4_8jptest361510 follows then: Red Hat Enterprise Linux AS release 4 (Nahant Update 7) rpm -qa | grep samba samba-3.0.33-0.18.el4_8.1 samba-client-3.0.33-0.18.el4_8.1 system-config-samba-1.2.21-1.el4.1 samba-common-3.0.33-0.18.el4_8.1 Tank´s
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0300.html