
CVE-2013-0871: Linux arbitrary kernel-mode code execution - friism
http://seclists.org/oss-sec/2013/q1/326
======
swanson
Hah! Where are the Linux neckbeards now? Another day, another Linux
vulnerability it seems like.

Honestly, how much longer are we going to build on this house of shaky cards?

Did they really think that letting a race condition happen on PTRACE_SETREGS
was a good idea? Just for "elegance sake"? Come on.

Everyone could tell that none of ptrace/jctl callers actually want to wakeup a
TASK_WAKEKILL task, but they can't specify the necessary mask.

My startup still runs Cobol on Cogs in DOS (and we serve over 9000 requests
per second on a single DigitalOcean $5 box!).

~~~
StefanKarpinski
not sure if trolling or actually runs DOS

~~~
sp332
COBOL ON COGS is a joke, plus I'm pretty sure a true user would get the
spelling and capitalization right :) <http://www.coboloncogs.org/INDEX.HTM>

~~~
kintamanimatt
"(c) <DATE OVERFLOW>"

Oh dear!

------
onedognight
First, this is local exploit. Second, most distributions do not allow access
to realtime scheduling by regular users. In particular, a simple for(;;); at
the highest SCHED_FIFO priority will lock the box. You can check

    
    
       /etc/security/limits.conf
    

to see which users / groups are allowed a higher than normal rtprio.

That being said, often pulseaudio and/or jackd are given realtime priviledges,
so I assume people will be looking at them.

~~~
vetrom
RT privilege is not a prerequisite to this exploit, it only makes it 'easier'.

~~~
vetrom
As a matter of fact, I also just realized that it may be possible that nice-
ing the 'victim' process down to -20 may also make it easier, and is a non-
privileged operation almost everywhere.

------
adamnemecek
I really like this recent trend where stuff like this is getting posted and
(more importantly) getting upvoted.

~~~
jewel
For me a lot of it feels like noise. Back when I was in charge of security at
a payment processor I was subscribed to all the relevant mailing lists (as
required by the PCI DSS). Now that I'm working with something less valuable I
just rely on apticron + nullmailer to notify me of important security updates
to system packages, and the rails security mailing list for rails.

It'd be wonderful if something similar were implemented for rubygems. If
security updates were marked in some way, a cron job could scan my Gemfiles
periodically and then check each gem to see if any security updates have been
released.

~~~
adamnemecek
I know where you are coming from but I feel like the exploits that do make it
to the front page are pretty saucy.

------
FooBarWidget
There have been multiple local kernel exploits in the past few years. For
somebody who doesn't constantly watch seclists.org or similar security sites,
how do I find out whether my kernel is vulnerable to any known exploit? Is
there a tool that can help me with checking? Is there a notification tool?

~~~
0x0
Your distro probably has a mailing list for announcing updates.

For debian, you should subscribe to <http://lists.debian.org/debian-security-
announce/> \- and you'll get an email as soon as updates are published. These
are also published at <http://www.debian.org/security/>

You can also follow security bugs closely on the security tracker. For
example, this vulnerability is classified here: <https://security-
tracker.debian.org/tracker/CVE-2013-0871> and the full list of bugs affecting
the stable kernel is here: [https://security-
tracker.debian.org/tracker/source-package/l...](https://security-
tracker.debian.org/tracker/source-package/linux-2.6)

------
bcoates
A lot of uses of ptrace require root on many distros, does this vulnerability
work when that's enabled?

edit: as in, does yama.ptrace_scope prevent anyone without root and/or
CAP_SYS_PTRACE from exploiting this?

~~~
tedunangst
No, you can exploit this by ptracing your child. It's not targeting a special
process. (Does anybody use yama.ptrace_scope?)

~~~
sounds
Has anyone estimated the probability of success? What is the average number of
attempts to get the scheduling conditions to happen?

Assume the user can get access to a CPU core that is otherwise idle.
sched_setaffinity(2) will succeed when run by the process to set its own
affinity to a specific core, so the attacker can locate the processes on a
chosen core. (The attacker could spend a few milliseconds first to find an
idle core.)

------
ck2
Did centos 2.6.32-279.22.1.el6 address this on Feb 6th or is this something
new?

Oh wait, nope, not addressed:
<https://rhn.redhat.com/errata/RHSA-2013-0223.html>

I thought the responsible thing to do was not announce it until there was some
headstart time?

Strangely it's not in the redhat db yet at all

<https://access.redhat.com/security/cve/CVE-2013-0871>

~~~
rbanffy
> I thought the responsible thing to do was not announce it until there was
> some headstart time?

I may be wrong, but from the report, it seems to be a somewhat difficult local
exploit that can lead to privilege escalation. While it's serious in that it
allows arbitrary code to run in kernel space, it also seems to pose a low risk
due to how hard it is to put all the required pieces in place.

Also, there are already corrections available.

------
ineedtosleep
Is this a vulnerability across all Linux versions or some of the more recent
versions (e.g. 3.7.x)?

------
ck2
So correct me if I am wrong, to disable ptrace?

    
    
       echo 0 > /proc/sys/kernel/yama/ptrace_scope
    

Grsecurity kernels also seem to have

    
    
       /proc/sys/kernel/grsecurity.harden_ptrace

~~~
andri
According to
[https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening...](https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace%20Protection)
setting it to zero would actually restore the more permissive behavior. But,
like someone here mentioned, a value of 1 would still allow to ptrace your own
process children.

------
csense
Can anyone explain what access is necessary to use this attack?

I'm guessing anyone with shell access (can run arbitrary shell commands from
an unprivileged account) will be able to use this to get root. But that's just
a guess; kernel experts are welcome to weigh in.

~~~
thefreeman
There isn't even a working exploit yet. As someone else mentioned, they
include a kernel patch with their proof of concept to allow you to reproduce
it.

~~~
thirsteh
A PoC and an exploit are equivalent. Attackers have saved the time trying to
figure out how to leverage it.

------
batgaijin
SELinux wouldn't stop this, right?

~~~
brokenparser
I think you _can_ use SELinux to prevent this attack. See
<http://fedoraproject.org/wiki/Features/SELinuxDenyPtrace>

