User: Password:
|
|
Subscribe / Log in / New account

Local root vulnerability in the kernel

Local root vulnerability in the kernel

Posted May 15, 2013 15:05 UTC (Wed) by dowdle (subscriber, #659)
Parent article: Local root vulnerability in the kernel

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


(Log in to post comments)

Local root vulnerability in the kernel

Posted May 15, 2013 18:42 UTC (Wed) by aliguori (subscriber, #30636) [Link]

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.

Local root vulnerability in the kernel

Posted May 15, 2013 21:05 UTC (Wed) by landley (subscriber, #6789) [Link]

echo 2 > /proc/sys/kernel/perf_event_paranoid

Local root vulnerability in the kernel

Posted May 15, 2013 21:40 UTC (Wed) by spender (subscriber, #23067) [Link]

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

Posted May 15, 2013 21:14 UTC (Wed) by landley (subscriber, #6789) [Link]

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

Posted May 16, 2013 0:46 UTC (Thu) by aliguori (subscriber, #30636) [Link]

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.

Local root vulnerability in the kernel

Posted May 17, 2013 2:57 UTC (Fri) by deater (subscriber, #11746) [Link]

> 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

Posted May 16, 2013 16:31 UTC (Thu) by robert_s (subscriber, #42402) [Link]

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

Posted May 16, 2013 22:18 UTC (Thu) by geofft (subscriber, #59789) [Link]

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

Posted May 17, 2013 8:52 UTC (Fri) by robert_s (subscriber, #42402) [Link]

Ah, thanks, misunderstood.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds