+++ This bug was initially created as a clone of Bug #532940 +++ Several race condition flaws were found in samba-client, fuse and ncpfs packages: a, Ronald Volgers found a race condition in the samba-client's mount.cifs utility. Local, unprivileged user could use this flaw to conduct symlink attacks, leading to disclosure of sensitive information, or, possibly to privilege escalation. Upstream bug report: https://bugzilla.samba.org/show_bug.cgi?id=6853 Upstream Samba patches: http://git.samba.org/?p=samba.git;a=commit;h=3ae5dac462c4ed0fb2cd94553583c56fce2f9d80 http://git.samba.org/?p=samba.git;a=commit;h=a065c177dfc8f968775593ba00dffafeebb2e054 http://git.samba.org/?p=samba.git;a=commit;h=a0c31ec1c8d1220a5884e40d9ba6b191a04a24d5 Issue severity note for Red Hat Enteprise Linux: ------------------------------------------------ The mount.cifs binary, as shipped within samba-client package on Red Hat Enterprise Linux 4 and 5, is NOT shipped with setuid root bit enabled by default (local, unprivileged users on these systems are NOT able to mount custom CIFS filesystem shares), which mitigates the impact of the vulnera- bility. b, Dan Rosenberg found a race condition in the FUSE's fusermount's utility by performing FUSE filesystem(s) unmount operation (it was not performed atomically). A local, unprivileged user could use this flaw to cause a denial of service (unprivileged unmount of FUSE filesystem share(s) owned by privileged user) via symlink attack involving FUSE share(s) belonging to privileged user. Issue severity note for Red Hat Enterprise Linux: ------------------------------------------------- The "fusermount" utility, as shipped within "fuse" package in Red Hat Enterprise Linux 5 IS shipped with setuid root bit enabled by default, but the unprivileged user to be able to mount custom FUSE filesystem, he needs prior to be the member of special "fuse" users group (user membership in this group is granted by privileged user), which mitigates the impact of the vulnerability. c, Dan Rosenberg found race conditions in the ncpfs ncpmount and ncpumount utilities. Local, unprivileged user could use these flaws to conduct symlink attacks, leading to denial of service (ncpumount), disclosure of sensitive information, or, possibly to privilege escalation (ncpmount). Issue severity note for Fedora: ------------------------------- The "ncpmount and ncpumount" utilities, as shipped within "ncpfs" package in Fedora release of 11 and 12 are NOT shipped with setuid root bit enabled by default (unprivileged, local users are NOT able to mount / umount custom remote NCP shares), which mitigates the impact of the flaws. MITRE has rejected the use of CVE-2009-3297 because it was used for samba, ncpfs, and fuse when it should only have been used for Samba. Instead, new CVEs have been assigned as follows: CVE-2010-0787: samba CVE-2010-0788: ncpfs CVE-2010-0789: fuse This issue does not affect Red Hat Enterprise Linux 4 and 5 by default as mount.cifs is not provided with the setuid bit enabled. If a user has turned on the setuid bit (via 'chmod +s /sbin/mount.cifs'), they would be affected by this issue and can workaround the problem by removing the setuid bit. Red Hat Enterprise Linux 3 does not provide the mount.cifs program. The Red Hat Security Response Team has rated this issue as having low security impact, a future update may address this flaw. More information regarding issue severity can be found here: http://www.redhat.com/security/updates/classification/
This issue has been addressed in Samba packages in Fedora: Fedora 12: samba-3.4.5-55.fc12 Fedora 11: samba-3.4.5-0.47.fc11
A few notes regarding mount.cifs since the above description isn't quite accurate, and to further clarify why this issue is of low impact. It notes a "disclosure of sensitive information" but I do not believe that is at accurate, or even likely on a properly-configure system. The problem is more that a user can gain privileges or mount a CIFS share at an arbitrary mount point (i.e. mounting a remote CIFS share over an existing directory like /tmp or /etc/pam.d). This does not immediately mean there is a disclosure of sensitive information unless they are able to mount over something like /var/log/ and capture log files (which does not seem likely without a syslog restart as log files will already be open). Tested by mounting a CIFS share over /var/log and having tailed /var/log/secure prior to the mount; syslog continues to log to the real /var/log/secure on a subsequent ssh login, as evidenced by: Apr 7 16:06:36 odvrhel5 sshd[6045]: lastlog_filetype: Couldn't stat /var/log/lastlog: No such file or directory Apr 7 16:06:36 odvrhel5 sshd[6045]: lastlog_openseek: /var/log/lastlog is not a file or directory Also, because mount.cifs is not suid root by default, a normal user cannot use it to mount CIFS shares, which limits the exposure of this problem. This is true even when CIFS mounts are defined in /etc/fstab; if mount.cifs is not suid the "user" option to mounts in fstab does not work but rather returns the error (in Fedora 12): /sbin/mount.cifs: not installed setuid - "user" CIFS mounts not supported. and in Red Hat Enterprise Linux 5: mount error 1 = Operation not permitted Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) So the only way this can be exploited by an end-user is if the administrator has an fstab CIFS share defined to a directory that a user can write to (i.e. the user has privileges to write to /mnt/foo and the CIFS share is mounted to /mnt/foo/cifs; if the user can remove the cifs/ directory to replace with a symlink, in which case the root-mounted CIFS share will be mounted where the symlink points to). To fully mitigate this issue, ensure that CIFS shares are mounted in directories that users cannot write to. Also note that although the mount.cifs(8) manpage does not explicitly indicate that enabling the suid bit on mount.cifs is discouraged, upstream indicates that mount.cifs should not ever be installed suid root (which is the case in all supported versions of Red Hat Enterprise Linux and Fedora): https://bugzilla.samba.org/show_bug.cgi?id=6853#c2
Acknowledgements: Red Hat would like to thank the Debian Security Team for reporting this issue. The Debian Security Team acknowledges Ronald Volgers as the original reporter.
This issue has been addressed in following products: Red Hat Enterprise Linux 4 Red Hat Enterprise Linux 5 Via RHSA-2011:1219 https://rhn.redhat.com/errata/RHSA-2011-1219.html
Statement: (none)