fusermount hardening #268
Merged
fusermount hardening #268
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently, in the kernel, copy_mount_options() copies in one page of userspace memory (or less if some of that memory area is not mapped). do_mount() then writes a null byte to the last byte of the copied page. This means that mount option strings longer than PAGE_SIZE-1 bytes get truncated silently. Therefore, this can happen: user@d9-ut:~$ _FUSE_COMMFD=10000 fusermount -o "$(perl -e 'print ","x4000')" mount sending file descriptor: Bad file descriptor user@d9-ut:~$ grep /mount /proc/mounts /dev/fuse /home/user/mount fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0 user@d9-ut:~$ fusermount -u mount user@d9-ut:~$ _FUSE_COMMFD=10000 fusermount -o "$(perl -e 'print ","x4050')" mount sending file descriptor: Bad file descriptor user@d9-ut:~$ grep /mount /proc/mounts /dev/fuse /home/user/mount fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=100 0 0 user@d9-ut:~$ fusermount -u mount user@d9-ut:~$ _FUSE_COMMFD=10000 fusermount -o "$(perl -e 'print ","x4051')" mount sending file descriptor: Bad file descriptor user@d9-ut:~$ grep /mount /proc/mounts /dev/fuse /home/user/mount fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=10 0 0 user@d9-ut:~$ fusermount -u mount user@d9-ut:~$ _FUSE_COMMFD=10000 fusermount -o "$(perl -e 'print ","x4052')" mount sending file descriptor: Bad file descriptor user@d9-ut:~$ grep /mount /proc/mounts /dev/fuse /home/user/mount fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1 0 0 user@d9-ut:~$ fusermount -u mount I'm not aware of any context in which this is actually exploitable - you'd still need the UIDs to fit, and you can't do it if the three GIDs of the process don't match (in the case of a typical setgid binary), but it does look like something that should be fixed. I also plan to try to get this fixed on the kernel side.
The old code permits the following behavior:
$ _FUSE_COMMFD=10000 priv_strace -etrace=mount -s200 fusermount -o 'foobar=\,allow_other' mount
mount("/dev/fuse", ".", "fuse", MS_NOSUID|MS_NODEV, "foobar=\\,allow_other,fd=3,rootmode=40000,user_id=1000,group_id=1000") = -1 EINVAL (Invalid argument)
However, backslashes do not have any special meaning for the kernel here.
As it happens, you can't abuse this because there is no FUSE mount option
that takes a string value that can contain backslashes; but this is very
brittle. Don't interpret "escape characters" in places where they don't
work.
If an attacker wishes to use the default configuration instead of the system's actual configuration, they can attempt to trigger a failure in read_conf(). This only permits increasing mount_max if it is lower than the default, so it's not particularly interesting. Still, this should probably be prevented robustly; bail out if funny stuff happens when we're trying to read the config. Note that the classic attack trick of opening so many files that the system-wide limit is reached won't work here - because fusermount only drops the fsuid, not the euid, the process is running with euid=0 and CAP_SYS_ADMIN, so it bypasses the number-of-globally-open-files check in get_empty_filp() (unless you're inside a user namespace).
Blacklists are notoriously fragile; especially if the kernel wishes to add some security-critical mount option at a later date, all existing systems with older versions of fusermount installed will suddenly have a security problem. Additionally, if the kernel's option parsing became a tiny bit laxer, the blacklist could probably be bypassed. Whitelist known-harmless flags instead, even if it's slightly more inconvenient.
Before:
$ _FUSE_COMMFD=1 priv_strace -s8000 -e trace=mount util/fusermount3 /proc/self/fd
mount("/dev/fuse", ".", "fuse", MS_NOSUID|MS_NODEV, "fd=3,rootmode=40000,user_id=379777,group_id=5001") = 0
sending file descriptor: Socket operation on non-socket
+++ exited with 1 +++
After:
$ _FUSE_COMMFD=1 priv_strace -s8000 -e trace=mount util/fusermount3 /proc/self/fd
util/fusermount3: mounting over filesystem type 0x009fa0 is forbidden
+++ exited with 1 +++
This patch could potentially have security
impact on some systems that are configured with allow_other;
see https://launchpad.net/bugs/1530566 for an example of how a similar
issue in the ecryptfs mount helper was exploitable. However, the FUSE
mount helper performs slightly different security checks, so that exact
attack doesn't work with fusermount; I don't know of any specific attack
you could perform using this, apart from faking the SELinux context of your
process when someone's looking at a process listing. Potential targets for
overwrite are (looking on a system with a 4.9 kernel):
writable only for the current process:
/proc/self/{fd,map_files}
(Yes, "ls -l" claims that you don't have write access, but that's not true;
"find -writable" will show you what access you really have.)
writable also for other owned processes:
/proc/$pid/{sched,autogroup,comm,mem,clear_refs,attr/*,oom_adj,
oom_score_adj,loginuid,coredump_filter,uid_map,gid_map,projid_map,
setgroups,timerslack_ns}
Nikratio
reviewed
Jul 17, 2018
| @@ -790,10 +820,16 @@ static int do_mount(const char *mnt, char **typep, mode_t rootmode, | |||
| flags |= flag; | |||
| else | |||
| flags &= ~flag; | |||
| } else { | |||
There was a problem hiding this comment.
Not sure about this. Is passing unknown options to the kernel really a significant attack surface? It has the drawback that it requires updating libfuse when the kernel starts supporting a new option.
| * This can be dangerous if it e.g. truncates the option "group_id=1000" to | ||
| * "group_id=1". | ||
| * This wrapper detects this case and bails out with an error. | ||
| */ |
There was a problem hiding this comment.
Thanks for noticing that!
roboshim
reviewed
Jul 30, 2018
There was a problem hiding this comment.
The autofs 0x00000187 should be as well allowed:
fusermount: mounting over filesystem type 0x00000187 is forbidden
I have created mount wrapper for sshfs over fuse for autofs. CD to some autofs folder runs sshfs to this folder and mount the server:/folder over sshfs. Now I cannot use it.
Maybe some "additional fs type white list option" in fuse.cfg would help.
Thank you for the update.
Regards.
Robert.
|
Makes sense to me. Could you provide a pull request? Please don't forget to add a brief entry to ChangeLog.rst as well. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Some of these patches are bugfixes for issues that I believe to be non-exploitable, the others are hardening changes that should make
fusermountmore robust against potential future problems.