I've been trying to draw attention to this issue via the vendor-sec mailing list to no avail. I've copied my vulnerability report below: mount.cifs, and umount.cifs are vulnerable to race conditions that allow unprivileged users to create denial of service conditions. All of these mounting utilities create "/etc/mtab~" as a lockfile before updating /etc/mtab, deleting the lockfile after finishing. By starting the mounting or unmounting process using either of these utilities and then sending a SIGKILL to the process at the right moment, the lockfile will not be cleaned up. The existence of this stale lockfile will cause most mounting utilities to abort, denying service. While the use of /etc/mtab~ is standard practice for mount utilities, suid versions such as these should use safer locking techniques that expire on process termination, since they can be killed mid-execution by unprivileged users. Signal handling is not an option, since SIGKILL cannot be caught. I have working exploit code available on request if you're having trouble reproducing the issue. As far as I know, this issue has not been assigned a CVE.
(In reply to comment #0) > > As far as I know, this issue has not been assigned a CVE. > Nor should it. The samba team does not recommend that mount.cifs be installed setuid root, and in upcoming releases the ability to run it setuid root will be disabled at compile time. I'm working on a set of patches to change that however, but they're not quite ready and they don't fix this issue. Note also that umount.cifs is considered deprecated in modern samba versions. > While the use of /etc/mtab~ is standard practice for mount > utilities, suid versions such as these should use safer locking techniques that > expire on process termination, since they can be killed mid-execution by > unprivileged users. What exactly is this safer locking technique that you recommend? It's not sufficient to lock mount.cifs against invocations of itself. We have to follow the convention that /bin/mount uses or the locking is worthless. I suppose we can try to mask out signals while updating the mtab, but I don't believe that SIGKILL can be masked out. Is there some way to make a setuid process immune to SIGKILL from an unprivileged user? Could I have it setuid(0), for instance?
What I think we need to do is to call "setreuid(0,0)" before doing the mtab locking. That'll block unprivileged users from sending signals to the program. root will still be able to send a signal to kill it though and users will still be able to hit ^c to break out of it. I'll queue up a patch to do that in the setuid patchset I'm working on.
(In reply to comment #2) > What I think we need to do is to call "setreuid(0,0)" before doing the mtab > locking. That'll block unprivileged users from sending signals to the program. > root will still be able to send a signal to kill it though and users will still > be able to hit ^c to break out of it. > > I'll queue up a patch to do that in the setuid patchset I'm working on. > Thanks for the quick response. This makes sense. I was under the mistaken assumption that it would be sufficient to lock against other invocations of mount.cifs, but this is clearly not the case, so I have no suggestions as to a safer locking mechanism, unless fcntl() with mandatory locking would work (I'm not especially well versed in this though). You're correct that SIGKILL cannot be masked, and also that setreuid(0,0) will prevent the user from sending a SIGKILL to the process. However, the user can still ^c to break out of it, and if the timing is right, it may still be possible to leave a stale lockfile. It seems as though this is a difficult issue to solve. This solution is sufficient to prevent easy exploitation, but maybe using file locks for mount programs should be reconsidered if unprivileged users are given suid mount utilities.
Yes, I think we probably need to mask signals as well so that races with ^c aren't possible. A better locking scheme would probably be welcome, but that needs to be a wholesale overhaul in multiple programs. There are vague plans to eventually build a "libmount" that mount helpers could use to do things like mtab addition and removal, option parsing, etc... Once that exists and most mount helpers are using it, changing the locking scheme becomes a bit more feasible. For now though, I think we're sort of stuck with what /bin/mount does. Stoplights only work if everyone is looking at the same ones.
Jeff: any change here in the meantime?
Nope. I'm not sure this bug is really so much an issue these days since modern distros have turned /etc/mtab into a symlink to /proc/self/mounts. In any case, this should probably be in Pavel's queue...