LWN: Comments on "A story of three kernel vulnerabilities"

Sure CAN disable unused filesystems =:^)

Duncan — Tue, 12 Mar 2013 03:59:30 +0000

On gentoo anyway, turning off such filesystem support, and automount support in general, is easy. Appropriate USE flags and kernel ensure support for this is NOT builtin. Of course whether you consider gentoo "a reasonably obvious way" or not is up to you, but...

My gentoo/kde systems are build without udisks, policykit, etc support, the appropriate USE flags turned off, both due to the heavy dependencies (udisks-1 wanted lvm2, udisks2 wants gparted while I use gptfdisk, I need those installed like I need another hole in my head!). And the kernel is built for the specific system it's on, monolithic, module support turned off. (Tho I did have to package.provided a couple runtime deps, including kdesu, that I didn't need anyway. I could of course have edited and overlaid the ebuilds to kill the runtime deps, but that would have been a repeated edit over many updates. Package.provideing them only need be done once.)

So no automounting or GUI superuser access and for SURE no support for obscure filesystems!

Where specific privlege-required functions are to be used by the GUI user, I configure sudoers to allow the specific command, no more, no less, with or without password required, depending on the need and how locked down the command actually is. Yes, that does require that the user use the commandline for it, but IMO, if a user isn't comfortable using the commandline, they have no business running superuser/privileged commands in the first place.

Of course that's a bit drastic for many, but that's precisely the point, gentoo, being build from source by the user, allows turning off unneeded features at end-user-controlled build-time, as opposed to centralized distro decided "someone might use it so we better enable it" defaults, at /their/ buildtime. If you want automount, turn on the appropriate USE flags, else turn them off and don't even have the otherwise required components installed in the first place. Actually, it's more than that, in effect, over time gentoo STRONGLY ENCOURAGES observance of the security "only install what you actually use" rule, because otherwise you're repeatedly building updates for stuff you don't use anyway, so if you're not actually using it, it quickly becomes simpler to just turn it off and not worry about building it any more.

So yes, there's a "reasonably obvious" way to turn them off... switch to a distro (and desktop, if necessary, but I'd guess gnome on gentoo allows turning it off too, I just don't know for sure as I don't use it) that allows it, if yours doesn't. =:^)

Duncan

Can't disable unused filesystems

nix — Mon, 04 Mar 2013 15:27:58 +0000

In effect udisks has been unmaintained for ages. I've reported several bugs that could well be security holes upstream (writes through null pointers, writes through uninitalized, pointers, the code quality is really quite dire). Not one has ever got a response.

Can't disable unused filesystems

cortana — Sun, 03 Mar 2013 15:42:10 +0000

udisks does provide properties you can use to prevent volumes from being mounted by and/or shown to the user, so this should be possible. The churn is a huge pain in the arse, however. And I see it's about to get worse, since udisks is being replaced by udisks2... :/

Can't disable unused filesystems

jmorris42 — Sat, 02 Mar 2013 16:59:17 +0000

Yea, /etc/filesystems is documented as only being consulted for -t auto or leaving the switch off entirely. If you explicitly specify a filesystem you expect the system to do what you told it.

But the key point remains, after several replies nobody can point to a way to actually solve a problem that exists on all graphical desktops.

udev is clearly not intended to be modified by the end user. It isn't documented, the files controlling it are written in a way to be hostile to manual editing and the entire subsystem has been churning for years.

Simply stopping the modules from loading isn't a good solution either.

You can't even reliably suppress the icons from appearing on a desktop. I once found a way to do it, it worked until the next Fedora.

A story of three kernel vulnerabilities

lopgok — Fri, 01 Mar 2013 17:56:17 +0000

I think the SELinux is real security 'progress in a _mainline_ distro'.

It is in the mainline kernel.
It is enabled by default in RHEL and fedora and perhaps elsewhere.
I heard it is even in the newest Android builds.

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

Wol — Thu, 28 Feb 2013 21:20:10 +0000

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

A story of three kernel vulnerabilities

geek — Thu, 28 Feb 2013 06:40:04 +0000

"...for most of that time, it was assumed that the problems had been fixed."
Isn't that, in principle, a testable assumption? I'd be interested to know if there is a testing discipline around such an assumption, I suppose it isn't the only time this has occurred.

Dave

Can't disable unused filesystems

spender — Sun, 24 Feb 2013 15:40:59 +0000

Grsecurity can do this. It happily prevents udisks from auto-loading modules for whatever filesystems on behalf of unprivileged users. It's unfortunate though that Linux is moving in this direction (of security decisions being made in userland brokers) as it hinders the ability to enforce more secure mandatory security policies.

Grsecurity will also prevent mount from being able to load arbitrary kernel modules (it will be restricted to modules that register a filesystem).

This is a subset of the full GRKERNSEC_MODHARDEN feature which prevents unprivileged users from being able to auto-load kernel modules, without having to implement a posteriori blacklists.

-Brad

Can't disable unused filesystems

paulj — Sun, 24 Feb 2013 08:49:28 +0000

Ah, so I'm not the only frustrated by lots of "disk" icons appearing in nautilus, that are to do with the system, and there not being any reasonably obvious way (either from UI or in /etc) to hide them?

Arg!

Can't disable unused filesystems

cortana — Sat, 23 Feb 2013 12:39:52 +0000

It might be possible to implement something like this today with udev rules... if you could set the UDISKS_SYSTEM_INTERNAL property on a disk based on the value of one of its partitions ID_FS_TYPE properties. However I don't know how well that would interact with more interesting disk layouts (e.g., NTFS filesystem inside a LUKS container only unlocked once the user has double-clicked on it in the GUI).

As for /etc/filesystems and /proc/filesystems, these days mount itself only seems to consult them if '-t auto' is used (or '-t' is absent entirely) and if libblkid fails to identify the correct filesystem. So I get the feeling that /etc/filesystems is really a remnant of an obsolete feature that hasn't been used since kernel module autoloading went in.

Can't disable unused filesystems

jmorris42 — Fri, 22 Feb 2013 23:13:22 +0000

Of course something else that would help if if Linux still had something resembling documented, knowable/controllable behavior. In the days of old /etc/filesystems declared which filesystems could be automatically detected and mounted, all others requiring an explicit mount with the -t switch to force detection of the filesystem.

That file still exists of course, and the mount command will still honor it when issued from a command line; but it is ignored by graphical desktops. And this defect is undocumented and if filed as a bug would be instantly closed as NOTABUG.

For example the machine I'm typing on dual boots Win7 and has an NTFS filesystem for it. Despite efforts to suppress it, it shows an icon on my desktop and if I right click it the desktop environment happily offers to mount it and it will succeed. Meanwhile /etc/filesystems is still the stock one supplied by Fedora. It lists vfat, hfs and hfsplus (why) but does not mention ntfs.

In a sane world a Linux desktop would not automatically mount rare filesystems, better still it would honor /etc/filesystems so the user could control it. Just how many users need hfs support? On a removable device? Close enough to zero it should default to no. These days ext[234],vfat,ntfs,iso9660 and udf probably should default to supported with everything else off.

A story of three kernel vulnerabilities

ortalo — Fri, 22 Feb 2013 10:36:19 +0000

Am I mistaken or don't we have every other year a report showing that linux kernel security bugs are fixed very slowly? It started approximately since linux itself gained significant reputation in that area against proprietary operating systems (so nearly forever).
I think it's FUD. Admittedly that's an uninformed comment because I am so convinced of that, that I do not even take the time to read the reports in question anymore...
But I'd like to outline something factual: I see 2 CVE ids here from 2009.
In 2009 only, there were over 5500 CVE ids. The evolution of the number of CVE entries since 2000 is, in my opinion, a much more interesting topic [1].
Now my question for Trustwave: who funded that research?

Just my 2/5500 cents...

[1] BTW, I have a graph of that data at http://rodolphe.ortalo.free.fr/COURS_SE_2012_r3.pdf, page 15, but everyone can grab it from cve.mitre.org

A story of three kernel vulnerabilities

jtc — Fri, 22 Feb 2013 05:41:09 +0000

'The Trustwave "analysis" obviously has a severe bias and its sample size makes it a joke.'

Not only is their analysis biased, but, if the zdnet summary of their report is to be believed, they've shown themselves to be incompetent:

"Zero-day flaws — software vulnerabilities for which no patch is available — in the Linux kernel that were patched last year took an average of 857 days to be closed, Trustwave found. In comparison zero-day flaws in current Windows OSes patched last year were fixed in 375 days."

The obvious implication is that this is a claim that the average of time to close for all zero-day defects in the Linux kernel is 3 years (versus 375 days for Windows). Obviously, an average cannot be calculated from 2 instances, which are very likely worst-case, out of many critical defects. Such miscalculation, of course, implies incompetence (or the zdnet summary is inaccurate). The criticism that these 2 cases took too long to fix is, perhaps, warranted, but nobody paying attention will conclude from their report that the implication of the headline ("Linux trailed Windows in patching zero-days in 2012...") is anything other than bullshit.

Interestingly, at the end of the zdnet article is:

"The Trustwave report says the number of critical vulnerabilities, as determined by the Common Vulnerability Scoring System (CVSS) assessment of factors like potential impact and exploitability, identified in the Linux kernel was lower than in Windows last year, with nine in Linux compared to 34 in Windows. The overall seriousness of vulnerabilities was also lower in Linux than Windows, with Linux having an average CVSS score of 7.68 for its vulnerabilities, compared to 8.41 for Microsoft."

This might be viewed as evidence that Trustwave is not biased, but, unfortunately for them in light of their main (apparent) claim, not as evidence that they are not incompetent.

A story of three kernel vulnerabilities

alonz — Thu, 21 Feb 2013 19:40:34 +0000

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

zlynx — Thu, 21 Feb 2013 19:13:57 +0000

I'd rather have an ASN1 parser in there than yet another custom format. At least ASN1 is well defined and doesn't shift its meaning on different machine architectures.

A story of three kernel vulnerabilities

drag — Thu, 21 Feb 2013 16:20:15 +0000

I am guessing that those numbers are the worst case scenario when it comes to the viewpoint of the attacker. I would expect that there are a significant number of things that can be done to improve the odds.

A story of three kernel vulnerabilities

alankila — Thu, 21 Feb 2013 15:03:03 +0000

To inject some numbers to this claim, and unless I am badly mistaken, the failure chance is 99.999999%. Raising that number to the power of approximately 70 million yields around 50 % success probability. It is fundamentally a matter of chance, so 100% success can never be achieved, though something very close to it can be achieved, of course.

In any case this sort of probabilities require means to fire the attack several times per second or it will probably take years of continuous attempting before succeeding. Unfortunately ptrace sounds like the sort of thing you can try thousands of times per second.

A story of three kernel vulnerabilities

Trou.fr — Thu, 21 Feb 2013 11:55:13 +0000

Stuxnet used a vulnerability in the Windows shell (the so-called LNK vulnerability), not in the filesystem code.

As for floppies, viruses spread mostly by running infected executables, not using vulns.

A story of three kernel vulnerabilities

corsac — Thu, 21 Feb 2013 06:16:30 +0000

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;...

A story of three kernel vulnerabilities

draco — Thu, 21 Feb 2013 03:16:47 +0000

There's nothing about signing stuff that requires ASN.1 or X.509. Also, it's entirely possible that userspace uses ASN.1/X.509 to get at the keys to sign with, but something else to carry the signature itself.

If the kernel must parse ASN.1/X.509 to parse the signature for authentication...yikes, but that's not a requirement. (And even if they are, I hope it's a really limited implementation.)

Filesystem vulnerabilities

PaXTeam — Thu, 21 Feb 2013 01:55:32 +0000

the CVE process has nothing to do with how fast a bug is fixed. it's only concerned with cataloging bugs, disclosure/fix/etc strategy is always up to the vendor/author. so if you had a problem with rushed fixes in the past, look no further than your own managers who forced you to do it.

Filesystem vulnerabilities

dgc — Thu, 21 Feb 2013 01:06:09 +0000

> Vendors seem not to consider filesystem vulnerabilities to be serious
> (including Red Hat who I work for).

Vendors take them extremely seriously, but there's lots more to the process than "OMG!!! Security Problem! World ends at 5pm if we don't have a fix by then!". As a filesystem developer (who co-incidentally works for Red Hat, too) I have fixed my fair share of fsfuzz related bug reports over the years.

So, what's the real issue here? It's that most fuzzer "filesystem vulnerabilities" are either a simple denial-of-service (non-exploitable kernel crash), or are only possible to exploit when you *already have root* or someone does something stupid from a security perspective. However, once a problem is reported to the security process it is captured, and the security process takes over everything regardless of whether subsequent domain-expert analysis shows that the bug is security problem or not.

> For example OpenStack out of the box will mount untrusted guest
> filesystems on the host kernel,

This is a prime example of "doing something stupid from a security perspective". Virtualisation is irrelevant here - the openstack application is doing the equivalent of picking up a USB stick in the car park and plugging it into a machine on a secured network.....

However, to really understand the situation from an fs developer POV you need to understand a bit of history and a bit about risk. That is, any change to filesystem format validation routines has risk of causing corruption or false detection of corruption, and hence you can seriously screw over the entire filesystem's user base with a bad fix.

Think about it for a moment - a divide by zero crash on a specifically corrupted filesystem is simply not something occurs in production environments. However, the changes to the code that detects and avoids the problem is executed repeatedly by every single ext4 installation in existence. IOWs, the number of people that may be affected by the corrupted filesystem div0 problem is *exceedingly tiny*, while the number of people that could be affected by a bad fix is, well, the entire world.

Then consider that the CVE process puts pressure on the developers to fix the problem *right now* regardless of any other factors. Hence the fixes tend to rushed, not well thought out, are only lightly tested and not particularly well reviewed. In the filesystems game, than means the risk of regressions or the fix not working entirely as intended is significant.

In the past this risk was ignored for security fixes, and that's why we have a long history of needing to add more fixes to previous security fixes. We have proven that the risk of regressions from rushed fixes is real and it cannot be ignored. Hence -in this arena- the CVE process could be considered more harmful to users than leaving the problem unfixed while we take the usual slower, more considered release process. i.e. the CVE process (and measuring vendor performance with CVE open/close metrics) simply does not take into account that fixing bugs badly can be far worse for users than taking extra time to fix the bug properly.

Vendors that do due diligence (i.e. risk assessment of such bugs outside of the security process) are more likely to correctly classify fuzz-based filesystem bugs compared to the security process. Hence we see vendors mitigating the risk of regressions by testing the filesystem fixes fully before releasing them rather than rushing out a fix just to close a CVE quickly.

IOWs, -more often than not- vendors are doing exactly the right thing by their user base with respect to filesystem vulnerabilities. The vendors should be congratulated for improving on a process that had been proven to give sub-standard results, not flamed for it...

-Dave.

A story of three kernel vulnerabilities

andrel — Wed, 20 Feb 2013 23:59:25 +0000

Supposedly Stuxnet was transmitted using a USB key.

A story of three kernel vulnerabilities

raven667 — Wed, 20 Feb 2013 21:23:58 +0000

There is far far far more than that when it comes to complex interfaces. Aside from the arbitrariness of ioctl there is bpf and GPU command validation as well as iptables and who knows what else that is passing complex data structures into the kernel.

A story of three kernel vulnerabilities

corsac — Wed, 20 Feb 2013 20:44:49 +0000

And about support for signed modules: I'm sure everyone loves having an X509/ASN1 parser running in ring0.

A story of three kernel vulnerabilities

josh — Wed, 20 Feb 2013 20:33:32 +0000

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.

A story of three kernel vulnerabilities

bfields — Wed, 20 Feb 2013 16:24:30 +0000

In the late eighties/early nineties I seem to recall infected floppy disks were the main (or at least a very common) vector for virus transmission.

If people don't exchange data on usb keys as much as they used to on floppies, perhaps that wouldn't be as effective these days.

A story of three kernel vulnerabilities

drag — Wed, 20 Feb 2013 16:07:38 +0000

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

drag — Wed, 20 Feb 2013 16:01:45 +0000

> 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

robert_s — Wed, 20 Feb 2013 14:48:32 +0000

>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

drag — Wed, 20 Feb 2013 14:31:32 +0000

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

Trou.fr — Wed, 20 Feb 2013 13:52:10 +0000

well it's a "real" issue but it's nothing compared to others that have a wide security impact as in every script kiddie can pwn a webserver :
1) outdated CMS with remote code execution (mostly PHP)
2) easy execution of any executable
3) ready to use exploit that works reliably as unprivileged user

The HFS+ vuln is not exploitable in that case. While it can be used for "physical" attacks like the USB key, it is not usable remotely.

_Thousands_ of servers have been compromised with that scenario :
1) vulnerable webapp
2) escalation to root using kernel vulnerability (or poor sysadmin)
3) ssh backdoor to collect passwords
4) compromise other hosts, goto 3
5) use compromised servers as DDoS platforms, proxy, whatever...

A story of three kernel vulnerabilities

robert_s — Wed, 20 Feb 2013 13:39:31 +0000

>In an ideal world of course, it would be possible to run all filesystem drivers as FUSE modules or in kernel.

Replying to myself - upon reading to the bottom of these comments it seems libguestfs can do this to some extent.

Perhaps a security-conscious distribution should consider doing auto-mounting of any "removable" block devices through such a mechanism.

A story of three kernel vulnerabilities

robert_s — Wed, 20 Feb 2013 12:48:38 +0000

Because the people who use rarely used filesystems don't want them to be fast?

In an ideal world of course, it would be possible to run all filesystem drivers as FUSE modules or in kernel.

Filesystem vulnerabilities

rwmj — Wed, 20 Feb 2013 10:42:47 +0000

Vendors seem not to consider filesystem vulnerabilities to be serious (including Red Hat who I work for). Yet they are very serious when you add virtualization into the mix.

For example OpenStack out of the box will mount untrusted guest filesystems on the host kernel, so all you need to do is upload a malicious filesystem image to a public cloud in order to attack the host and any other VMs running on the same system.

We (Red Hat) have worked to mitigate this by using libguestfs which adds several layers of protection between a malicious filesystem and the host:

http://libguestfs.org/guestfs.3.html#security-of-mounting...

But with sysadmins still using kpartx / loopback mounting, there's still a need to take fs vulnerabilities much more seriously.

A story of three kernel vulnerabilities

renox — Wed, 20 Feb 2013 10:30:52 +0000

> I concur with spender's remark, the vulnerabilities could have been selected to underline a real problem with security and not just metrics with a DoS nobody will ever trigger (the ext4 one is a joke).

"could have been"? What about the HFS+ exploit?
As joey remarked above, it is a real issue..
By focusing on the ext4 DOS, you "forget" the other issue.

A story of three kernel vulnerabilities

josh — Wed, 20 Feb 2013 09:54:46 +0000

I'd argue that rarely-used filesystems (90% of the "Miscellaneous Filesystems" menu in kconfig) ought to become FUSE modules running in a seccomp sandbox, having only the permissions they need to read or write the mounted device and respond to FUSE requests.

A story of three kernel vulnerabilities

epa — Wed, 20 Feb 2013 09:17:01 +0000

Yes, they took a biased sample. But that's the thing about security: you cannot rely on the law of averages to help you. An attacker only needs to be lucky once. If Trustwave can cherry-pick three vulnerabilities which took a long time to fix, an attacker can do the same. So it is quite legitimate to criticize the state of security fixes based on one security hole left unpatched, even if there were a thousand others fixed promptly.

A story of three kernel vulnerabilities

error27 — Wed, 20 Feb 2013 07:17:45 +0000

$ mount -o loop foo mnt
mount: only root can do that

But otherwise yes, the fuzzer uses loop back filesystems for testing. The thing about USB sticks is that most distros automount them when you plug them in.

Probably they should not automount less used filesystems.

A story of three kernel vulnerabilities

smurf — Wed, 20 Feb 2013 07:12:58 +0000

Definitely.