Local root vulnerability in the kernel

echo 2 > /proc/sys/kernel/perf_event_paranoid

By the way, "sandboxing" won't help a kernel that's running in ring 0 from something that lets you write to arbitrary memory; if you want to switch perf off don't load the module or drop it from your .config, a distro flinging everything at the wall and then adding _more infrastructure to switch it off again seems kinda silly. (Neither will selinux's whack-a-mole rules: if it's unknown, by definition you haven't got a rule for it yet.)

As the old saying goes, you either make the system simple enough there are obviously no vulnerabilities, or you make it complicated enough there are no obvious vulnerabilities.

(Of course "unknown" is relative. I'm curious about http://www.exploit-db.com/exploits/25444/ having "2010" in the copyright-like notice up top. I know the israeli secret service and russian kleptocracy and such have way better fuzzers than open source has bothered with until recently, the main protection for Ubuntu systems is we're less than 1% of the installed base so nobody _cares_. I'd worry more about android phones getting morris-wormed with something like this...)

Um, are you suggesting here that the use of QEMU over just plain application-in-a-sandbox gives you any added security?

Quite. I'd say this security bug was about as serious as the obscure ext4 bug that ate my filesystem: both have serious consequences, but neither is going to happen unless you make some unusual changes to your system: in my case, mounting with certain mount options and then rebooting in the middle of a umount; in this case, turning on a config option which pretty much screams SECURITY PROBLEMS HERE, and which can't be turned on in conjunction with a lot of other commonly-used options which are probably already on. I know I wasn't faced with the *option* to turn on userspace namespaces until 3.9: many people, e.g. those using XFS, probably still can't see it. In both cases the fault was really one of documentation: the ext4 mount option didn't say it was experimental and dangerous, so tweakers-for-tweaking's-sake like me might well turn it on without realizing the danger; this option, too, was missing that disclaimer in the Kconfig help text.

So basically you would like to see every one running the latest kernel from kernel.org ?

Conversely, it demonstrates the danger of running newer kernels. The vuln was not present in older kernels, as newer kernels bring with them not only silent vuln fixes but also new, poorly-tested vulnerable code to exploit. (user namespaces anyone?)

Let's meet in the middle and say it demonstrates the danger of running Linux kernels ;)

-Brad

I didn't respond to the first part of your post yet.

You are correct that I don't agree with how the vulnerabilities are handled. However, you're incorrect that I agree with your first sentence. I feel that it's a form of a logical fallacy employed to excuse the handling of vulnerabilities.

-Brad

>to a large degree, just about any kind of kernel bug is a security issue; to a large extent that's just the nature/role of the kernel.

I would mostly agree with this statement as well, but I would point out that one can subdivide "security issue" into different categories. Here are some possible categories:

1. Denial of service
2. Leaking of privileged information
3. Modification of privileged information
4. Privilege escalation
5. Loss of user data

I would aggregate 2, 3, and 4 into a single bucket because historically they have frequently been found to be equivalent. It seems to me that this was a #3 bug and (again given historical trends) should have been treated as if it was a #4 bug. It clearly wasn't.

Perhaps if kernel programmers attempted to classify bugs using something like the above categories and then treated ones that fell into the more sensitive buckets as if they were security problems, this kind of thing could be prevented. Under the current system, we seem to be assuming that all kernel programmers are also security experts and can accurately assess the security implications of all of their code/bug fixes. This seems a little too much to ask even of them.

> GregKH and others handle it by saying "you really should be updating, because we don't know beforehand which of these bugfixes will have an exploit developed".

But that is exactly opposite of what is so often being requested. If developers don't know, that's fine.

The issue is that the problems that are _known_ to have security impact are not reported as such.

From that analysis:

> The interrupt descriptor table was chosen because it is very easy to get it's address even on hardened builds -- using sidt instruction.

That reminded me of the following commit, which was merged for 3.10:

https://git.kernel.org/linus/4eefbe792baedb474e256d353708...

> Make a copy of the IDT (as seen via the "sidt" instruction) read-only. This primarily removes the IDT from being a target for arbitrary memory write attacks, and has the added benefit of also not leaking the kernel base offset, if it has been relocated.