
Simple kernel attack: Eat 100% CPU, works under guest, no way to protect - tableton
http://lkml.org/lkml/2010/11/25/8
======
Rantenki
Has anybody launched this in a VM under Xen and/or EC2 to see if AWS is
vulnerable? If this can mangle the Dom0 over a paravirt DomU, this would be
awfully interesting.

/me off to test...

update: Would be nastier if it forked cpux2 times or something at startup. My
test server is running fine for 15 minutes with it active. A bit slow, but
still responsive and accepting new SSH connections. Server is Centos 5.5 with
2.6.18-194.26.1.el5

Proc net unix seems stable as below, maybe slowly growing now.

[root@xenpig net]# cat /proc/net/unix | wc -l

153406

I have kill -9 that process several times though, and it ain't dying, so that
is an issue.

~~~
deutronium
You can cap the amount of CPU utilization for VMs, so I don't think you could
bring the server to a crawl, only the VM.

------
planckscnst
Apparently someone used this on the lkml.org web server.

------
tzury
I would call it an attack if you can inject it into someone's else machine
build it and run it as guest (or upload it as a binary and run it).

Writing a program which eats all available CPU and other resources it is not a
big deal, is it?

~~~
leif
There are other ways of gaining remote access. This is a pretty well-
constructed local DoS attack you can run (without root access, I think!).

Attacks can take many forms, most new attacks are single components that one
would combine to perform a real-world attack.

Here, you would combine some method of gaining remote access (maybe a
webserver hole you can drop a shell with) with this and get an excellent
remote DoS attack.

~~~
saurik
One really easy way of getting remote access is to ask for it. Local exploits
and DoS attacks are important not just because other exploits may let you run
code remotely: there are many situations in which computers are not single-
user devices. At my university anyone can remotely log in to any of the
machines used as lab workstations and there are numerous shared fileservers
you can log in to as well. People also still routinely purchase "shell
accounts" on shared hosting providers.

------
caf
The thread is also viewable here:
[http://lkml.indiana.edu/hypermail/linux/kernel/1011.3/00630....](http://lkml.indiana.edu/hypermail/linux/kernel/1011.3/00630.html)

~~~
mrb
You linked to a thread that is not the original one.

The problem was originally reported 2 days earlier by Vegard Nossum:
<http://thread.gmane.org/gmane.linux.kernel/1067149>

~~~
kevingadd
The problem reported there is slightly different; the program linked in the OP
operates recursively, building a larger and larger graph of 'in flight' FDs,
while the earlier report simply allocates a bunch of pairs and sends FDs to
them. The earlier report is apparently fixable by triggering the GC in this
case (as mentioned in the lkml followup), but that fix does _not_ address the
exploit in the OP.

------
jasoncartwright
By installing Flash player?

~~~
mishmash
You made me laugh, but HN is no place for humor.

~~~
rw-
Yeah.

------
corin_
Not informed enough to say if the code is as interesting as the title implies.
Hope someone comments to enlighten me, shall upvote if so!

~~~
rwmj
You can send a file descriptor over a socket between two processes. (Google
"SCM_RIGHTS").

This is one place in the kernel where it employs a garbage collector (hey,
they need to start somewhere ...). The reason is that there's an uncomfortable
part about this API: the reader doesn't necessarily have to pick up the file
descriptor it is sent. If the sender closes the fd, the kernel needs to detect
that the reader didn't pick up the fd and deallocate the underlying file
resource. Hence GC needed.

This code makes sure that many such fds are "in flight" over the socketpair,
and by closing the socket instead of reading from it, ensures they are leaked.
The GC doesn't get invoked under this particular set of circumstances so
eventually you consume all system file resources. (I think even ulimit doesn't
stop this).

Solution as in the follow up message is to run the GC in an extra place.

~~~
tbrownaw
> and by closing the socket instead of reading from it, ensures they are
> leaked.

It does:

    
    
        create socketpair N+1
        send socketpair N over socketpair N+1
        close socketpair N
        repeat
    

So the only ones that are ever closed are the local copy of something that was
sent over another socketpair. So all of the fd's are reachable, assuming that
an in-flight fd is (like a received fd) a copy of the original fd rather than
a reference to it.

~~~
caf
Seems like in-flight fds should still count against the sending process's open
file limit. (So that all fds are counted against _some_ processes open file
limit).

------
chuhnk
Wait, is this run locally because I could just do :(){:|:&}; :& which is
pretty effective.

~~~
rcfox
Am I the only one who initially thought this was a sequence of emoticons?

~~~
johnswamps
I'm not sure why : has been chosen as the canonical fork bomb function name,
but it's more readable with something like

resurse() { recurse | recurse &}; recurse

~~~
marbu
In this example, the poor readability is a feature. Nevertheless the ":"
character is bash inner function, which tells the shell to do nothing (except
the arguments expansion), like pass in python. This means that you can
redefine it and use it to confuse others. Most of other special characters are
not functions so you are not able to redefine them that easily.

------
abscondment
What happens if you renice the process so everything else takes priority?

~~~
tonfa
Probably nothing, since it happens in the kernel, not in userspace.

------
shin_lao
Isn't it possible to mitigate the problem in limiting the number of sockets an
user process may open?

------
hackermom
Despite knowing it was aimed at Linux, which I don't use, I still had to try
it out to settle my curiosity: it's completely harmless on OpenBSD and Mac OS
X; it does not hang either of these OS' kernels, and does not eat FDs.

~~~
kidsat
BSD doesn't support SOCK_SEQPACKET on unix domain sockets. The app exits
early.

------
rw-
Shame on you, Марк Коренберг! Releasing ready-to-use exploits harms everybody.

~~~
Fargren
It also let's people prepare for it and create solutions. It's not a bad
policy, and not releasing the exploit can in many cases be more harmful.

~~~
RexRollman
Exactly. Disclosure is best.

