A story of three kernel vulnerabilities

Posted Feb 20, 2013 14:31 UTC (Wed) by drag (guest, #31333)
In reply to: A story of three kernel vulnerabilities by robert_s
Parent article: A story of three kernel vulnerabilities

I don't see the benefit of using 'FUSE' from a security perspective.

FUSE still goes to through kernel file system interface, and then you have all the file system code, and the setuid fuse binaries and special permissions that the user has to have to access /dev/fuse.

It seems to me to be a attempt to throw code and complexity to obsofgate (sp?) a potential security hole. It just seems to be a better to approach just to fix the code.

Also I am pretty sure that if somebody plugs a device into a machine they have the full intention of mounting it to see what is on it. Having a 'ack' button may be useful in a case where you do not want a device mounted while you are away from the computer and the screen is locked, but besides that having a extra step the user must go through to mount it would serve little purpose. It may make people feel more comfortable or help people (like me) that tend to do odd things with flash file systems that precludes mounting them.

This is the case were potentially some sort of 'anti-virus' code may be useful to validate the device before mounting it, but that seems to open up a whole new can of worms.

A story of three kernel vulnerabilities

Posted Feb 20, 2013 14:48 UTC (Wed) by robert_s (subscriber, #42402) [Link] (3 responses)

>I don't see the benefit of using 'FUSE' from a security perspective.

Well you'd better tell the authors of libguestfs then (largely RedHat) as security seems to be its main intention.

If you're saying that an exploit granting access to a user space program is just as dangerous as it having access to kernel space, I think most people would disagree with you.

The point is not whether or not the user wants to mount the device - let's take it for granted that they do, so confirmation is irrelevant. It's whether that USB stick that was just handed to them at a conference is able to directly exploit their kernel on insertion through a specially crafted filesystem.

"Just fix"ing "the code" in this case means "always getting all filesystem code 100% right 100% of the time".

A story of three kernel vulnerabilities

Posted Feb 20, 2013 16:01 UTC (Wed) by drag (guest, #31333) [Link] (2 responses)

> If you're saying that an exploit granting access to a user space program is just as dangerous as it having access to kernel space, I think most people would disagree with you.

No.

I am saying that taking a security problem that exists in kernel space and then trying to fix it by moving to a mixture of kernel space and userspace and throwing in a couple setuid root binaries isn't a silver bullet.

Fuse requires kernel file system features as well as setuid root binaries to operate properly. Without granting users access to /dev/fuse you can't 'mount' fuse file systems. Just granting users the ability to use fuse is a security risk in itself.

Now if you were to say that you wanted to use something like GVFS, which itself doesn't require any special privileges or fuse mounts or anything like that, then that's different. That is completely in a user account, but it's not POSIX compatible and requires programs to be GVFS aware.

A story of three kernel vulnerabilities

Posted Feb 20, 2013 16:07 UTC (Wed) by drag (guest, #31333) [Link] (1 responses)

Oh and as far as 'userspace vs kernelspace', since all this stuff requires root privileges to do, unless you want to depend entirely on GVFS and whatnot, then any exploit that gives you root access gives you kernel access. Pretty much same different, unfortunately.

A story of three kernel vulnerabilities

Posted Feb 21, 2013 19:40 UTC (Thu) by alonz (subscriber, #815) [Link]

The only setuid binary involved with using FUSE is "fusermount", which only opens /dev/fuse and immediately drops privilege. The filesystem handler itself runs as an unprivileged user.

So I, for one, really don't get your point.

A story of three kernel vulnerabilities

Posted Feb 20, 2013 20:33 UTC (Wed) by josh (subscriber, #17465) [Link]

Just running in userspace doesn't necessarily give you an inherent security advantage, especially if running as the primary user on the system. However, many more facilities exist to isolate and sandbox userspace binaries to protect against exploits. For instance: take a kernel filesystem driver, port it to FUSE, and run the actual process that does filesystem parsing inside of a seccomp sandbox that only has permission to read and write the mounted device and respond to FUSE requests. Then, even if that filesystem parsing got exploited, the exploit can do very little to harm the system. It could crash, slow down filesystem accesses, serve up arbitrary file content (already possible if you control the filesystem image), or burn CPU, but it can't make arbitrary system calls and can't easily escalate privileges.

they have the full intention of mounting it to see what is on it

Posted Feb 28, 2013 21:20 UTC (Thu) by Wol (subscriber, #4433) [Link]

Not at all.

Assuming the automount works even if the screen is locked (as I get the impression is often the case), this is a perfect way of breaking into someone else's machine. If the exploit opens a root shell on a secret port, that machine is now owned ...

So in that case, the user knows exactly what is on it. They want to see what's on the machine.

So a confirmatory pop-up (as I get on my gentoo system) *is* a very effective security step.

Cheers,
Wol