Date: Fri, 4 Sep 2015 20:42:10 -0400 (EDT) From: cve-assign@...re.org To: siddharth@...hat.com, fw@...eb.enyo.de Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: CVE Request for glusterfs: fuse check return value of setuid -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > https://bugzilla.redhat.com/show_bug.cgi?id=1254488 > http://review.gluster.org/#/c/10780/ > https://github.com/gluster/glusterfs/commit/b5ceb1a9de9af563b0f91e2a3138fa5a95cad9f6 > it is a grave security error to omit checking > for a failure return from setuid() We don't understand why this would be true in all cases. It can be a security error to omit checking for a failure return from setuid, if the motivation for calling setuid is to drop privileges. If the motivation for calling setuid is to increase privileges, then sometimes this "omit checking" behavior is only a usability bug, or is not a bug at all. We haven't traced the glusterfs code in detail, but we think the scenario may be the following: - the only goal in calling setuid is to execute /bin/mount (or /bin/umount) from a process with both an effective UID of 0 and a real UID of 0. This is a requirement of the util-linux mount program. See the "if we're really root and aren't running setuid" comment in mount.c. Otherwise, for the types of mount usage in question, mount would print "mount: only root can do that" and exit. - the "setuid (geteuid ());" calls that were changed are in the glusterfs fuse_mnt_add_mount and fuse_mnt_umount functions - as far as we know, no part of the glusterfs code can call fuse_mnt_add_mount or fuse_mnt_umount unless "geteuid () == 0" is true - see mount_fuse, add_mount, fuse_mount_sys, main, unmount_fuse_locked, unmount_fuse, and gf_fuse_unmount - in other words, fuse_mnt_add_mount and fuse_mnt_umount are not calling setuid to drop privileges; they are calling setuid to try to ensure that the real UID becomes 0 - if the setuid call fails and the real UID remains nonzero, the immediate impact is that the /bin/mount child process exits, with a nonzero status, without doing the requested mount. Then the calling function returns -1. No code ever runs with higher-than-intended privileges. - if an attacker is able to conduct an RLIMIT_NPROC attack against use of the setuid system call by glusterfs, probably the attacker could just as easily conduct an RLIMIT_NPROC attack against use of the fork system call by glusterfs. That would also cause the calling function to return -1. - we also aren't sure that anyone would have any motivation for conducting an RLIMIT_NPROC attack - thus, it seems that the original code had only a minor usability problem: in the presence of an RLIMIT_NPROC attack against use of the setuid system call, /bin/mount would refuse to mount anything and glusterfs itself would not print an informative error message As far as we can tell, there's no vulnerability: an attacker cannot ever achieve anything useful by arranging for a glusterfs setuid system call to fail. We can't assign a CVE ID unless there's different information. > From: Florian Weimer <fw@...eb.enyo.de> > Date: Tue, 18 Aug 2015 14:44:51 +0200 > Original code: > > <http://sourceforge.net/p/fuse/fuse/ci/master/tree/lib/mount_util.c#l103> > > Pluse two more locations in that file. The fuse mount_util.c file has a unique third case in the remove_mount function to support "umount --fake" calls. (glusterfs doesn't support - --fake.) The code behavior in this case may be different because - --fake might not require a real UID of 0. However, our guess is that this is also a situation where no code ever runs with higher-than-intended privileges, and no CVE ID can be assigned. - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJV6jngAAoJEL54rhJi8gl5mdMQAJ3dbHo6SocjCVrslGy85vCd 1+YdStE2T5Ppq6Nzs3Vcw0mYbG8wo0j4FCJTkzSBPS5OV6AyFWIsfHHX76hOsrp1 uVouamdh3lGbzracDKUpm6/Zt2/R+7my0MnmzhyvKWL2NNSsuodNix+MvPSvp9ry 7CjQzYVzVYEa/WtqW856yA+ye7p9AqFGhBJPB8giOV2HwuAytzgXkeVhrG5r/Zmu agYCs+pFJwUrmgkHmDYtyfQP5Ue4kA/peSo+6L/9cJ+NTC/7zm4Liw+kgj819pF2 RZ2790NadXgXIYXtMv471BUkA9mFYeljcuajIQ2y/XTTH9aB/NgnhCtRLzLBkAKW D7EPkrWQ2r9ZTPf/p3n714Kt76mAyXkcUy4vrSAPGBH+y0bvBJ+1HezhceHy1M+b wtxy3x8UkemdM1ZndSzSN3KtqYvZRi44O+KCPhZXp34tzFEI8h0gTH/7vUb4X3t5 xX2OXzokBQe9urwQj0E63N4az1hj6gcKezVfLiq+YDHSYa/dCkiuaDZbMzVyLhLT UP1WYohvaDYkuewKwTn8Q9tz+iMfnfAR2i7FcTUQ9Mcs6RXcPIknEjirZXmP0wd4 DetOlnPsBN7vf6zrgGuh1D0TIi2WnKSFR3nNg58vuSc2SuazcQFaUVkRG0rtt92h dV2/n9JTP9Dem1GX9HQs =Scls -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ