Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri,  4 Sep 2015 20:42:10 -0400 (EDT)
Subject: Re: CVE Request for glusterfs:  fuse check return value of setuid

Hash: SHA256


> 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

  - 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

> From: Florian Weimer <>
> Date: Tue, 18 Aug 2015 14:44:51 +0200

> Original code:
> <>
> 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 ]
Version: GnuPG v1


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.