LWN: Comments on "Local root vulnerability in the kernel"

Local root vulnerability in the kernel

nix — Wed, 22 May 2013 16:45:33 +0000

Yeah, I was firing at the wrong thing. Misread, drag and ewan and you are right.

One problem with the rather nice LWN Recent Comments thing is a lack of context, and it sometimes leaves you astray :)

Local root vulnerability in the kernel

spender — Tue, 21 May 2013 20:32:44 +0000

You guys are talking past each other.

I mentioned (as an example) user namespaces as something new in the kernel that introduced significant vulnerability not present in earlier kernels.

Drag then commented about the vulnerability that the article is about (the perf events vuln) being as significant as an ext4 data corruption bug.

You then mentioned about how you wouldn't be hit by this vulnerability without extensive changes to your system. I believe you were referring to user namespaces here, but drag was referring to perf events. CONFIG_PERF_EVENT is forced on (why?) for anyone using X86.

Ewan then followed up saying basically what I just said in the above paragraph, referring to the exploit released that was mentioned in this article, but without explicitly mentioning perf events you still understood him to be talking about user namespaces.

All sorted now! :)

-Brad

Local root vulnerability in the kernel

nix — Tue, 21 May 2013 14:33:04 +0000

RHEL6 has user namespaces turned on?! That's... riskier than I would have expected from RH. I boggle.

Local root vulnerability in the kernel

vonbrand — Tue, 21 May 2013 01:54:52 +0000

Kernel programmers haven't got the time, nor the training, to try and classify each patch (ranging from wording in a comment, code reorganization for clarity, up to new subsystems) into your four buckets (there are in fact hundreds of other buckets to consider).

Local root vulnerability in the kernel

robert_s — Fri, 17 May 2013 08:52:11 +0000

Ah, thanks, misunderstood.

Local root vulnerability in the kernel

deater — Fri, 17 May 2013 02:57:30 +0000

> if you want to switch perf off don't load the module or drop
> it from your .config,

perf can't be compiled as a module, and as far as I know it can't be turned off on x86 since about 2.6.37 or so. I'll be glad to be proven wrong on that count though.

It's true any user/kernel interface leads to issues like this, but it doesn't help that perf has such a complex interface (check out the manpage for it sometime). We might have been better off if a simpler perf counter interface (like perfctr or perfmon2) that was closer to a thin layer abstracting the MSRs had been merged instead.

Local root vulnerability in the kernel

geofft — Thu, 16 May 2013 22:18:02 +0000

He's speaking as an application developer, where the application he happens to develop is qemu. The claim is that other applications should do the same sandboxing to themselves as qemu does to itself -- there's no suggestion that apps should be run _inside_ qemu.

Local root vulnerability in the kernel

robert_s — Thu, 16 May 2013 16:31:49 +0000

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

Local root vulnerability in the kernel

dowdle — Thu, 16 May 2013 16:27:47 +0000

Red Hat has released an updated kernel.

Local root vulnerability in the kernel

charlieb — Thu, 16 May 2013 13:39:38 +0000

Posting misinformation yet again?

Local root vulnerability in the kernel

aliguori — Thu, 16 May 2013 00:46:46 +0000

It's really quite simple. The kernel/userspace boundary is huge with more stuff going in all of the time.

Applications that are high risk need to proactively isolate themselves and reduce that boundary.

Let's not kid ourselves here. If you have local user privileges and can run arbitrary code, SELinux or not, I'm quite confident there are more 0days out there that you could use to elevate to root.

"unprivileged" users don't exist anymore.

More information

spender — Wed, 15 May 2013 23:46:04 +0000

Or as done in PaX's KERNEXEC since 2003. Who knew that my presentation on "Linux Security in 10 years" (http://grsecurity.net/spender_summit.pdf) would mention changes that took exactly 10 years? ;)

-Brad

Local root vulnerability in the kernel

ewan — Wed, 15 May 2013 23:22:08 +0000

"neither is going to happen unless you make some unusual changes to your system"

Er - what? This exploit works on RHEL 6 in its default configuration. It's not exactly the far reaches of exotica.

More information

cesarb — Wed, 15 May 2013 23:14:44 +0000

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.

Local root vulnerability in the kernel

spender — Wed, 15 May 2013 21:40:27 +0000

Please stop repeating this misinformation. It does not prevent exploitation. sd's public exploit needs only a single character modification (discussed in my post) to "bypass" this "fix".

-Brad

Local root vulnerability in the kernel

bojan — Wed, 15 May 2013 21:33:39 +0000

> 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.

Local root vulnerability in the kernel

landley — Wed, 15 May 2013 21:14:28 +0000

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...)

Local root vulnerability in the kernel

landley — Wed, 15 May 2013 21:05:10 +0000

echo 2 > /proc/sys/kernel/perf_event_paranoid

Local root vulnerability in the kernel

drag — Wed, 15 May 2013 21:03:08 +0000

It's not all that honest all the time. Certainly that can be part of it, but it's Linux kernel policy to not bring attention to bugs like this.

This has been brought up many times before on lwn.net.

There are a lot of people working with a lot of companies that market their products as being rather secure. They often see a distinct advantage to not admitting to problems because that makes their products look better when people compare vulnerability lists on places like Secunia.

Local root vulnerability in the kernel

nix — Wed, 15 May 2013 20:55:43 +0000

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.

Local root vulnerability in the kernel

drag — Wed, 15 May 2013 20:46:42 +0000

It seems that time has proven current policies as incorrect.

Sure, all security bugs can be security bugs, but once they are known to be security issues then that is a issue.

It should be treated with the same level of importance as, say, a bug in Ext4 that corrupts your file system. Nobody would suggest that should be downplayed and hidden like security bugs are in the Linux kernel.

Local root vulnerability in the kernel

landley — Wed, 15 May 2013 20:46:22 +0000

You could also try echo 2 > /proc/sys/kernel/perf_event_paranoid

Local root vulnerability in the kernel

fandingo — Wed, 15 May 2013 20:23:44 +0000

Not on the latest release. However, you should be using a kernel that is actively maintained, and you should be using the current version of that maintained series.

Kernel series being maintained (and hosted on kernel.org) are

mainline: 3.10-rc1 2013-05-12
stable: 3.9.2 2013-05-11
stable: 3.8.13 [EOL] 2013-05-11
stable: 3.7.10 [EOL] 2013-02-27
longterm: 3.4.45 2013-05-11
longterm: 3.2.45 2013-05-13
longterm: 3.0.78 2013-05-11
longterm: 2.6.34.14 2013-01-16
longterm: 2.6.32.60 2012-10-07
linux-next: next-20130515 2013-05-15

More information

nix — Wed, 15 May 2013 19:29:42 +0000

A damn good explanation, too.

Local root vulnerability in the kernel

nix — Wed, 15 May 2013 19:26:32 +0000

You're right in some areas, but here... I'm not sure user namespaces are a good example. If they're configured out there is no security risk, virtually no distro turned them on because many filesystems don't support them yet, they default to off because they're known to be not fully baked yet, and anyone who looks at something tricky and invasive like user namespaces and *doesn't* think 'hey, there are going to be multiple vulnerabilities, or at least horrible bugs, reported here while the design kinks are worked out' hasn't been using software very long.

Local root vulnerability in the kernel

aliguori — Wed, 15 May 2013 18:42:37 +0000

The one thing that does stop this vulnerability is seccomp() mode 2.

We have seccomp() support in QEMU and we do not have this system call in our whitelist. If an attacker was able to break into QEMU, sandboxing would stop the attempted privilege escalation.

It's a good example of why more applications should use sandboxing if they are likely attack targets.

More information

fuhchee — Wed, 15 May 2013 17:37:05 +0000

See also https://bugzilla.redhat.com/show_bug.cgi?id=962792#c16 for Petr Matousek's analysis.

More information

corbet — Wed, 15 May 2013 17:35:28 +0000

For the curious, Brad posted a detailed explanation of how the exploit works over on Reddit.

Local root vulnerability in the kernel

faramir — Wed, 15 May 2013 17:20:40 +0000

>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.

Local root vulnerability in the kernel

bluss — Wed, 15 May 2013 17:12:50 +0000

It suggests we need a deeper approach to security, to combat this on multiple levels. The newest kernels have some holes and the older kernels have others.

Local root vulnerability in the kernel

spender — Wed, 15 May 2013 17:07:37 +0000

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

Local root vulnerability in the kernel

spender — Wed, 15 May 2013 16:50:22 +0000

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

Local root vulnerability in the kernel

Trou.fr — Wed, 15 May 2013 16:43:14 +0000

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

Local root vulnerability in the kernel

arjan — Wed, 15 May 2013 16:31:01 +0000

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 know Spender does not really agree with how the kernel team handles these, but even Spender will likely agree with my first sentence.

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". They do not say "the planet is on fire" kind of thing. But the final thing is the same, you SHOULD update.

BTW, this also shows the danger of running older kernels, even if someone is backporting things for you; this bugfix might not have been picked up for backporting because there was no CVE for it.... this one got found and CVE'd so it'll be backported. But there are likely dozens similar changes with similar exposure for which no public exploit exists *yet*.

Local root vulnerability in the kernel

fuhchee — Wed, 15 May 2013 15:14:31 +0000

"It wasn't seen as a security bug"

There may be an element of wilful ignorance here. https://patchwork.kernel.org/patch/2441281/ clearly said "passed by user-space ... out-of-bounds access".

stap band-aid for kernel CVE-2013-2094

mjw — Wed, 15 May 2013 15:08:24 +0000

There is a quick and dirty systemtap guru mode band-aid script at https://bugzilla.redhat.com/show_bug.cgi?id=962792#c13 if you must really run an vulnerable kernel and cannot quickly upgrade.

Local root vulnerability in the kernel

spender — Wed, 15 May 2013 15:07:25 +0000

Something important missing from this summary is that while the exploit was posted yesterday, it was authored in 2010. The author of the exploit (and many previous exploits) discloses private exploits once he spots them being killed upstream: http://article.gmane.org/gmane.comp.security.oss.general/...

SELinux won't help, perf_event_paranoid=2 won't help -- for a right-thinking person, this could be seen as motivation for a change of course out of the ashes of such a dramatic failure. Unfortunately, I think Michael Gilbert is right on the money about what will really result from all this: http://seclists.org/oss-sec/2013/q2/329. Vulnerability patched, problem solved; rinse and repeat.

If your only source of protection against exploitation of the vulnerability is waiting on your distro to provide an updated kernel package, then it's already too late.

I posted more specific notes on exploitation here:
http://www.reddit.com/r/netsec/comments/1eb9iw/sdfuckshee...

-Brad

Local root vulnerability in the kernel

dowdle — Wed, 15 May 2013 15:05:58 +0000

Just wanted to mention that OpenVZ released an updated kernel fixing this yesterday. For anyone using OpenVZ, here's the info:

http://wiki.openvz.org/Download/kernel/rhel6/042stab076.8