|Summary:||sys-apps/util-linux: unintentional grant of privileges by umount (CAN-2005-2876)|
|Product:||Gentoo Security||Reporter:||Thierry Carrez (RETIRED) <koon>|
|Component:||Vulnerabilities||Assignee:||Gentoo Security <security>|
|Package list:||Runtime testing required:||---|
Description Thierry Carrez (RETIRED) 2005-09-13 07:36:37 UTC
From BugTraq <email@example.com> 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.
Comment 1 SpanKY 2005-09-13 16:57:04 UTC
ive added the small fix to our current stable/unstable ebuilds ... just need to revbump em, but i'd like to glance through bugzilla and see if i cant accumulate any other fixes at the sametime
Comment 2 Thierry Carrez (RETIRED) 2005-09-17 05:44:10 UTC
vapier: time to revbump if nothing else can be added...
Comment 3 Martin Schlemmer (RETIRED) 2005-09-18 04:59:10 UTC
We did add -r3 .. not sure if Mike want anything else in.
Comment 4 Thierry Carrez (RETIRED) 2005-09-18 09:38:11 UTC
Looks enough to me. Archs, please test and mark 2.12q-r3 stable
Comment 5 Markus Rothe (RETIRED) 2005-09-18 10:34:27 UTC
stable on ppc64
Comment 6 Luis Medinas (RETIRED) 2005-09-18 17:23:02 UTC
stable on amd64
Comment 7 Jason Wever (RETIRED) 2005-09-18 21:19:14 UTC
Stable on SPARC.
Comment 8 Mark Loeser (RETIRED) 2005-09-19 09:56:14 UTC
Stable on x86
Comment 9 Fernando J. Pereda (RETIRED) 2005-09-19 11:30:12 UTC
Stable on alpha
Comment 10 Michael Hanselmann (hansmi) (RETIRED) 2005-09-19 12:49:25 UTC
Stable on hppa and ppc
Comment 11 Hardave Riar (RETIRED) 2005-09-19 23:27:16 UTC
Stable on mips.
Comment 12 Thierry Carrez (RETIRED) 2005-09-20 07:49:29 UTC
GLSA 200509-15 arm, hppa and s390 should mark stable to benefit from GLSA