[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
