Re: CVE Request for glusterfs: fuse check return value of setuid

[cve-assign () mitre org]

-----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 () deneb 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-----