[<prev] [next>] [day] [month] [year] [list]
Message-ID: <200509122116.32711.baikie@ehwhat.freeserve.co.uk>
Date: Mon, 12 Sep 2005 21:16:32 +0100
From: David Watson <baikie@...hat.freeserve.co.uk>
To: bugtraq@...urityfocus.com
Subject: util-linux: unintentional grant of privileges by umount
Affected: Linux umount command as provided in the util-linux package in
versions 2.8 to 2.12q, 2.13-pre1 and 2.13-pre2.
Privileges needed to exploit: local account with permission to unmount a
user-mountable file system with Unix-type features (set-id bits or device
nodes).
Effect: removal of nosuid, nodev and other flags from the file system, thus
allowing setuid and setgid bits to take effect and device nodes to be
interpreted. While this may be undesirable in itself, someone who can write
to the underlying device or otherwise provide its contents can use this to
obtain root privileges (for example by creating a setuid-root binary in the
file system and having its setuid bit take effect when run).
Explanation:
When mounting a user-mountable file system, the mount command always imposes
the nosuid and nodev flags by default, and only the superuser or an explicit
setting in the fstab entry can override this. However, I recently discovered
that the umount command allowed users to remove these flags again by using
the -r option.
The -r option tells umount to try to remount the file system read-only if it
is currently busy and cannot be unmounted fully (for example, if it is the
current directory of some process). However, the file system is remounted
with the MS_RDONLY ("ro") flag alone, thus clearing all its other flags,
including nosuid and nodev. In the affected versions, the user who mounted
the file system can use this option and easily force the unsafe remount, even
if the file system is already read-only. If "users" was given in the fstab
entry, then any user can do so.
Workaround: edit /etc/fstab to limit the (un)mounting of filesystems
appropriately, or just remove the setuid bit from umount.
Fix: fixed in util-linux 2.12r-pre1 and 2.13-pre3, by refusing to accept
the -r option from a non-root user.
Powered by blists - more mailing lists