Bug 298651 - (CVE-2007-5159) ntfs-3g allows access to partition the users normally should not have access to
ntfs-3g allows access to partition the users normally should not have access to
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: ntfs-3g (Show other bugs)
rawhide
All Linux
urgent Severity low
: ---
: ---
Assigned To: Tom "spot" Callaway
Fedora Extras Quality Assurance
: Security
Depends On:
Blocks: F8Blocker
  Show dependency treegraph
 
Reported: 2007-09-20 13:34 EDT by Thorsten Leemhuis
Modified: 2007-11-30 17:12 EST (History)
3 users (show)

See Also:
Fixed In Version: 2.7.0-5.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-25 04:29:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Thorsten Leemhuis 2007-09-20 13:34:46 EDT
Description of problem:
Fuse in general and Fedora's way to let only members of the group fuse access
and use fuse was discussed in
https://www.redhat.com/archives/fedora-desktop-list/2007-September/msg00163.html
and mails below in that thread.

There we noticed that members of the group fuse can get access to devices which
they normally should not have access to. See
https://www.redhat.com/archives/fedora-desktop-list/2007-September/msg00163.html
; the relevant parts of it:

$ ls -l /dev/sda3
brw-r----- 1 root disk 8, 3 14. Sep 16:10 /dev/sda3
$ groups
thl fuse
$ dd if=/dev/sda3 bs=512K count=1 | strings
dd: opening `/dev/sda3': Permission denied
$ mkdir ntfs
$ /sbin/mount.ntfs-3g /dev/sda3 ntfs/
$ touch ntfs/foo
$ ls -l ntfs/foo
-rwxrwxrwx 1 thl thl 0 18. Sep 19:27 ntfs/foo

ntfs-3g IMHO should fail, as the users should not get access to random devices
he has no access to. Quoting Alexander Larsson from
https://www.redhat.com/archives/fedora-desktop-list/2007-September/msg00171.html

>Thats quite weird. The way I undestand fuse is that you run the
>filesystem as your user, and then that filesystem (via libfuse) spawns
>fusermount to open the fuse device and attach to the mountpoint.
>fusermount then passes the fd to the fuse device back the the filesystem
>process (via a socket) which then handles all the requests. 
>
>Reading the data source for the filesystem (if there is any) is only
>done by the filesystem process, not by the setuid fusermount helper, so
>it should not be able to read /dev/sda3.

Further investigation showed that ntfs-3g gets installed SUID root:

$ ls -l /sbin/mount.ntfs-3g 
-rwsr-xr-- 1 root fuse 40528 17. Sep 23:14 /sbin/mount.ntfs-3g

That might be wrong as that afaics makes it possible for ntfs-3g to access
devices which the user normally would not have access to. Quoting Alexander
again, this time from
https://www.redhat.com/archives/fedora-desktop-list/2007-September/msg00174.html

>Oh. That seems like a bad idea to me. If this drops privs after opening
>the device I think you can attach to the process using e.g. gdb and call
>any read() operation on the device. If might even mean (with some
>creative exploits) that any fuse group user can read any block on any
>disk.

Version-Release number of selected component (if applicable):
ntfs-3g-1.913-1.fc8

Please note that I as ex-maintainer of fuse stumbled into this by accident -- I
don't care much about fuse and ntfs-3g these days, but I think the behavior of
ntfs-3g is a security bug.
Comment 1 David Zeuthen 2007-09-20 14:44:03 EDT
I really think this is a security issue that needs dealing with.
Comment 2 Tom "spot" Callaway 2007-09-20 14:54:05 EDT
It seems like the obvious fix here is to not have ntfs-3g setuid. Agree?
Comment 3 David Zeuthen 2007-09-20 15:10:54 EDT
I think it makes sense to make any user user system-installed fuse file systems
PROVIDED they have access to the underlying block device or whatever resource is
backing the file system. E.g. if I use a FUSE module to access my gmail account,
it should be possible for me to mount it somewhere under $HOME without having
special privileges.

This is much like we allow any user to use any kernel file systems PROVIDED they
have access to the underlying block device (NFS, however, is special I believe).

But the important part here is really that /sbin/mount.ntfs-3g is letting you
use any block device you want just because you have access to /dev/fuse. That's
the fundamental flaw; that program needs to also check that the invoking
unprivileged user have access to the block device. 

I think the best solution is probably to avoid setuid and let pam_console manage
permissions on /dev/fuse. That way /sbin/mount.ntfs-3g probably wouldn't need to
run as root at all and mounting would only work if you have access to the
underlying block device.
Comment 4 David Zeuthen 2007-09-20 15:13:28 EDT
Thinking more about it making /dev/fuse mode 0666 and removing the setuid root
bit from /sbin/mount.ntfs-3g is probably what we need to do. Shrug.
Comment 5 Tom "spot" Callaway 2007-09-20 16:45:06 EDT
I just built and created an update for fuse and ntfs-3g (fuse-2.7.0-4.fc7,
ntfs-3g-1.913-2.fc7). Please test these when they hit to ensure that this
resolves the security problem and doesn't affect functionality.
Comment 6 Lubomir Kundrak 2007-09-21 04:38:13 EDT
The CVE identifier for this issue was requested.
Comment 7 Thorsten Leemhuis 2007-09-21 05:15:20 EDT
(In reply to comment #6)
> The CVE identifier for this issue was requested.

In case it matters: it works the same way on Ubuntu 7.10/Gutsy afaisc -- if you
are a member of the fuse-group there you as ordinary user can access devices
which you normally would have no access to.

Comment 8 Alexander Larsson 2007-09-21 05:28:14 EDT
/sbin/fusermount should be setuid, as its required for opening the fuse device
and attaching it to the mountpoint (similar to how /bin/mount is setuid) . It
should imho not be setuid for the fuse group, but for anyone so that normal
users can mount stuff in e.g. their own homedirs.

However, that is a far cry from having mount.ntfs-3g being setuid. As far as I
can tell the only reason for doing that is so that it can read the devices
containing the filesystem. But this at the same time basically means any user in
the fuse group can read any block device, which is horribly bad. 

Making it possible for ntfs to access the device as the user is better done in
other ways, like the admin chowning the particular device, or the user being in
the disk group.
Comment 9 Alexander Larsson 2007-09-21 07:13:21 EDT
davidz: Why should we change the ownership of /dev/fuse? I don't think that
helps any.

All that is needed is that fusermount is correctly setuid and executable by
everyone. It opens the device, verifies permissions (via config files and
whatnot) and calls the mount syscall. Then it hands over the resulting fd to the
non-privileged filesystem process.
Comment 10 Tom "spot" Callaway 2007-09-21 08:58:11 EDT
/dev/fuse was 660 before I changed it. I can change it back, if needed. Just let
me know. :)
Comment 11 David Zeuthen 2007-09-21 11:52:12 EDT
(In reply to comment #8)
> /sbin/fusermount should be setuid, as its required for opening the fuse device
> and attaching it to the mountpoint (similar to how /bin/mount is setuid) . It
> should imho not be setuid for the fuse group, but for anyone so that normal
> users can mount stuff in e.g. their own homedirs.
> 
> However, that is a far cry from having mount.ntfs-3g being setuid. As far as I
> can tell the only reason for doing that is so that it can read the devices
> containing the filesystem. But this at the same time basically means any user in
> the fuse group can read any block device, which is horribly bad. 
> 
> Making it possible for ntfs to access the device as the user is better done in
> other ways, like the admin chowning the particular device, or the user being in
> the disk group.

Or just mounting it via HAL; that's how it works post-Fedora 7. E.g. if you have
a dual-boot system your Windows partition should appear in Nautilus or KDE or
whatever and if you try to mount it you may encounter a one-time-pain PolicyKit
dialog asking for the root password. It's one-time-pain because you can select
to keep the privilege forever. This is all configurable via PolicyKit.conf so it
can be locked down any way the user desires.
Comment 12 David Zeuthen 2007-09-21 11:55:33 EDT
(In reply to comment #9)
> davidz: Why should we change the ownership of /dev/fuse? I don't think that
> helps any.
> 
> All that is needed is that fusermount is correctly setuid and executable by
> everyone. It opens the device, verifies permissions (via config files and
> whatnot) and calls the mount syscall. Then it hands over the resulting fd to the
> non-privileged filesystem process.

Right, it's probably better to make fusermount setuid root so it can access the
/dev/fuse file rather than making the /dev/fuse file accessible to everyone.
Alternatively (and maybe a bit more secure) make fusermount setgid fuse and make
/dev/fuse 0660. All that matters is that fusermount can open /dev/fuse; pick
whatever works and is most secure, right?
Comment 13 Thorsten Leemhuis 2007-09-21 12:52:03 EDT
(In reply to comment #9)
> davidz: Why should we change the ownership of /dev/fuse? I don't think that
> helps any.

Agreed.

(In reply to comment #10)
> /dev/fuse was 660 before I changed it. I can change it back, if needed. Just let
> me know. :)

Well, isn't making it 666 creating yet another problem? I'm not really sure, but
if the device it 666 then the user afaics could compile his own fuse and use the
device with it, thus circumventing the need to be a member of the fuse group to
use fuse in general(¹)? Or am I missing something/got something really wrong now?

(¹) -- which is afaik want we want for now, until "someone sits down and really
does audit fuse", as jeremy wrote in 
https://www.redhat.com/archives/fedora-desktop-list/2007-September/msg00151.html 
Comment 14 Tom "spot" Callaway 2007-09-21 13:06:01 EDT
After thinking about it, /dev/fuse should be chmod 660 (not 666), and fusermount
should be setuid root. I'm committing those changes now, and I'll respin the update.
Comment 15 Fedora Update System 2007-09-25 04:29:08 EDT
fuse-2.7.0-5.fc7, ntfs-3g-1.913-2.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 16 Thorsten Leemhuis 2007-09-25 04:43:10 EDT
(In reply to comment #15)
> fuse-2.7.0-5.fc7, ntfs-3g-1.913-2.fc7 has been pushed to the Fedora 7 stable
repository.  If problems still persist, please make note of it in this bug report.

Hmmm. Lot's of users will likely run into problems now and will wonder how to
make ntfs-3g work again -- wouldn't it be wise to do some formal announcement
why the change was done and how users can make it work again?

Comment 17 Jan Engelhardt 2007-09-27 04:02:56 EDT
How about just making /dev/fuse 666 and have no setuid/setgid bits set?
Comment 18 Thorsten Leemhuis 2007-09-27 06:57:47 EDT
(In reply to comment #17)
> How about just making /dev/fuse 666 and have no setuid/setgid bits set?

Then fuse afaik doesn't work at all.

BTW, we are discussing different things in this bug and that seems to become
more and more confusing afaics.

This bug was about ntfs-3g that could access hard disk partions it should have
no access to because it was SUID root -- spot fixed that (BTW: thx spot). 

But that's afaics mostly (totally?) independent of the /dev/fuse files, it's
permissions or the permissions of the fuse executables.
Comment 19 Szabolcs Szakacsits 2007-09-27 17:03:48 EDT
If mount(8) would execv euid=0 ntfs-3g (if the user has all the rights of
course) and fuse would allow unprivileged fuseblk mounts then everything would
work fine ntfs-3g non-setuid.

Btw, I think users can not get uncontrolled access to any devices by suid
ntfs-3g via this way, only to NTFS ones (which can be still more than it should
be). If the device is not NTFS then ntfs-3g exits without dropping the
privilege. Opening a device via strace/gdb/etc obviously fails.
Comment 20 Tomas Hoger 2007-10-01 04:09:41 EDT
CVE id CVE-2007-5159 was assigned to this issue.
Comment 21 Szabolcs Szakacsits 2007-10-06 08:09:46 EDT
I'm sorry to say but the Fedora and CVE advisories and security analyzes don't
look technically correct as of today. 

First of all, this issue has nothing to do with FUSE.

The reason why suid-root is needed in some cases is explained here:
http://ntfs-3g.org/support.html#useroption

Here is how suid-root ntfs-3g works:

unprivileged initialization (parsing options, etc)
gain privilege
load fuse module, fix missing fuse device
open(2) the device
immediately read the NTFS boot sector (first 512 bytes of the partition)
exit without dropping privilege if it's not NTFS.
mount with FUSE if the partition is NTFS.
drop privilege
function as a file system driver

Considering the above, could somebody please explain how a user, allowed to
mount NTFS partitions via the ntfs-3g file permission settings, could gain read
and write access to __arbitrary__ block device? What he can do are

1) gain information about if a device is NTFS or not
2) mount and read/write any NTFS partitions (file permission based, per device
restriction is not possible until mount(8) is fixed if 'user' and 'users' mount
option support is required).

So it's true that they get read/write access to any __NTFS__ block devices if
they were allowed to execute ntfs-3g but I fail to see how users could get
access to __any__ block devices via the way the advisories talk about.

Regards,  Szaka

--
NTFS-3G Lead Developer:  http://ntfs-3g.org

Note You need to log in before you can comment on or make changes to this bug.