Red Hat Bugzilla – Bug 577277
CVE-2010-0787 samba: Race condition by mount (mount.cifs) operations
Last modified: 2015-07-31 02:25:44 EDT
+++ 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:
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-
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
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
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:
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:
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: lastlog_filetype: Couldn't stat /var/log/lastlog: No such file or directory
Apr 7 16:06:36 odvrhel5 sshd: 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
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