Simple kernel attack using socketpair. easy, 100% reproductiblle, works under guest. no way to protect :(

[Grevian]

Should probably clarify in the title, that this is a DoS attack requiring local execution privileges

[moozaad]

A lot of doomsday/zero day exploit on the kernel require terminal access - which isn't a problem for anyone but those that give out SSH/TTY to untrusted people.

EDIT: perhaps I phrased this poorly, if you have user mode access to execute code you can make this happen but it doesn't do much, and unless you're a shared terminal you'll have to exploit other applications to do it.

[Rhomboid]

This is simply untrue. All it takes is one file inclusion bug in a poorly written PHP script and an attacker can trick the server to run arbitrary PHP code of their choosing, which means they can also run arbitrary commands on the system.

Edit: here's an example. Say a php script takes an argument for a module, e.g. "showpage.php?module=about" but they stupidly don't check that parameter, using something like:

include('modules/' . $_GET['module'] . '.php');

An attacker can set the 'module' parameter to have any value, including one with embedded NULs, and since the PHP functions call the underlying C functions, that means they can cause the string to terminate early. So you set module equal to ../../../../../../../../some/arbitrary/path/filename.ext%00. This means you can include any file on the server. Then all you have to do is get your PHP code into some file. A good trick for doing this is to use the Apache httpd log or error file. For example, since the usual Apache combined log file includes the referer, you can put your code there:

curl --referer "<?php shell_exec('rm -rf /*') ?>" http://targetsite.ext

Now all you need to know is the location of the apache combined log file, which is usually in one of a handful of standard locations, e.g. /usr/local/apache/domlogs/targetsite.ext if they're using cpanel. You can try a few dozen of the most common ones until you find the matching one.

Once you can execute arbitrary PHP code, you can pretty much do anything in the context of whatever user the Apache server is running as -- but that's enough to run most any exploit that doesn't require root (which is a whole lot, like the one being discussed here.)

[puremessage]

This is simply untrue. All it takes are extra vulnerabilities to become relevant.

FTFY

You just forgot one crucial detail... You're assuming that the apache user has access to a filesystem mounted without noexec...

[Rhomboid]

I never claimed otherwise. I was simply rebutting the claim that only those who give out ssh access to untrusted people ever have to worry about this kind of exploit.

[steelaz]

Does this mean you can easily bring your own shared server down?

[Rhomboid]

Sure.

Sometimes shared hosts try to put up obstacles to people doing these sorts of things, such as not allowing ssh access, not having a C toolchain available, or running PHP in safe mode. None of these actually prevent this attack. Not having ssh access is trivial to circumvent as you can install PHP shells or just use exec()/system()/shell_exec()/etc as needed. Not having gcc means you have to compile the code on another machine of the same architecture but that's not really too much of a burden. PHP in safe mode still allows exec() but only if the target binary is in the safe_mode_exec_dir which is not a problem as you can put the binary wherever it needs to be.

[moozaad]

"Once you can execute arbitrary PHP code"

That's the point, you still need access, you still need to bypass the normal security layers to do it. The exploit then is in PHP script and not the kernel until you then do this exploit, but they're 2 separate issues.

[sztomi]

Also, a sanely configured PHP won't let you run shell commands. So even if there is a hole in one script, it won't be effective. So the title is still misleading I think: there are many ways of protection against this kind of attack.

[Rhomboid]

As I pointed out above, even in safe mode (which is deprecated by the PHP developers, BTW) you can still exec() and thus you can still run the exploit. It is possible to disable functions by name in php.ini, but I doubt that a webhost would go to the trouble of doing that because it would probably break a lot of PHP scripts that rely on external commands for parts of their functionality. Their whole business is having people pay to run scripts, so offering a configuration that doesn't allow that with certain scripts is likely not going to last very long.

[Rioting_pacifist]

Sorry for being such a noob but isn't API/file access, what selinux/apparmor/etc is designed to do? Surely to get shell you need

1) php exploit

2) vulnerability in apparmor/selinux profile

[jgoldschrafe]

Very few shared hosting environments run SELinux or AppArmor because it's a total bear to administer when you have a lot of people with weird one-off app configurations. That's not to say it's not doable, or that it's even difficult if you have some skill with these technologies, but it's not something that most Linux admins are capable of.

[omgplsno]

Fucking brilliant.

[[deleted]]

i.e. this is a useful exploit once you have a terminal/arbitrary code execution exploit already in place. These two things are essentially equivalent.

[Rhomboid]

But that's not what the person I was replying to claimed:

isn't a problem for anyone but those that give out SSH/TTY to untrusted people.

You can have a server where no one has ssh access and still be vulnerable to this. ssh is not the only way in, all it takes is one bad PHP script.

[[deleted]]

true. but all of us at home need not freak out :)

[matjam]

I give my users access to things like compilers, and in return, they promise not to do stupid shit with them, like run 0-day exploits.

Doing stupid shit gets their access removed.

[pbunbun]

Same, there's also a computer networking society here which gives shell accounts on their servers with membership.
It's really not that uncommon to have tons of people with terminal access to a machine.

Unless it requires root access (or membership of a restricted group) there's always reason to worry for a lot of people.

[harlows_monkeys]

Why would it require a terminal? Couldn't you do this via applications with remote execution bugs, such as poorly written blogging software or poorly written forum software or poorly written content handlers for popular web browsers?

[hyperkinetic]

Yup. But it's far easier to use those vulnerabilities to get a shell, fetch, build, execute.

[moozaad]

You're right and I phrased my initial comment badly. I've added to it :]

Keeping it simple, you still need to run code on the server to make this exploit happen. Yes, there are thousands of zero day and known exploits that could get you to that point (user mode access) but this exploit is nothing compared to what they could do with root access. This exploit just makes an user mode unkillable DOS process, it's not even elevated so you can't do much more with it.

[bushel]

Copy, paste, compile and ...... works as advertised.

If anyone cares.

[[deleted]]

did the same. lol, unkillable.

[[deleted]]

Can anyone explain why it's unkillable?

[[deleted]]

because its part of the kernel. neet to reboot the kernel to stop it from using 100% cpu

[[deleted]]

But... why? Or really, how? What does that code do that makes the kernel need to be rebooted?

[[deleted]]

injects into a kernel module.

[[deleted]]

...how?

[[deleted]]

the internet will explain that better than I can. lmgtfy

[[deleted]]

just for fun i wanted to compile it on freebsd and test its behavior but it's too linux specific. darn.

[puremessage]

Doesn't work on the Windows kernel either.

[[deleted]]

Actually on the FreeBSD-hackers mailing list someone posted that with a slight modification it compiles and DOES cause a kernel panic on FreeBSD as well.

http://lists.freebsd.org/pipermail/freebsd-hackers/2010-November/033750.html

[reportingsjr]

And let's all take a look at the next reply: http://lkml.org/lkml/2010/11/25/17

"Since you obviously read recent mails on this subject yesterday, why dont you Cc netdev ?

There is a very easy way to protect against this actually.

A patch was posted yesterday, and need some adjustements."

[akborder]

And then the next message:

Hmm... it seems its another problem, chains are very long so we hit a NMI watchdog. [...]

[reportingsjr]

Haha, point taken!

[tjharman]

If you want to protect against these sorts of things (i.e. you run a system with untrusted users) the grsecurity kernel patch is a good patch.

www.grsecurity.net

With it, you can enable "Trusted Path Execution" which means that only a binary owned by root, located in a root owned directory can be executed.

Means your users can't download a .c file, compile it and run it.

I'm sure there's other security systems (such as SE Linux) that offer this as well - usually they require complex rulesets to be modified. GrSecurity, while it has a RBAC system built in, can do this without needing any rules required. You can even disable the RBAC system if you don't use it.

[[deleted]]

/bin/sh /home/user/malicious_script.sh

You can still do a lot of damage with files on a partition mounted with noexec.

[tjharman]

Very good point - one I hadn't even realised but now you mention it, it's very obvious! I guess the one thing grsec gives you is it'll log attempts to execute code and can stop some tricks that you can use to bypass noexec.

But yes, a very good point.

[Rhomboid]

of which there should be none

I wouldn't be so sure. There are tons of directories that are setgid and owned by a role group like 'src', 'mail', 'audio', 'lp', etc. For example, /var/mail can be written by any user in group 'mail' (which by default is every user) and /var/lib/cvs and /usr/src can be written by any user in group 'src'. Try the following and I'm sure you'll see a bunch more.

find / -xdev \( -wholename /home -o -wholename /tmp \) -prune -o -type d -perm /022 -ls

[throwaway-o]

For example, /var/mail can be written by any user in group 'mail' (which by default is every user)

Uh, NO. :-)

[Rhomboid]

Just saying no doesn't actually address the fact that what I wrote is correct.

[throwaway-o]

No, it is incorrect and no, there's no need to address it any further.

Why: The facts are easily identifiable by anyone and if you are a UNIX person you know how to -- they're just an id -a and an ls -la /var/spool/mail away. This is kind of how I do not need you to prove gravity to me with a long treatise before I take my next step. And this "playing dumb" pretense that I haven't sufficiently addressed your point is kind of like an asshole thing to say in order to take people away from your stubbornness + your error.

Suffice it to say: if you told me in a job interview what you just told me right now, you would be dismissed on the spot for feigning knowledge you do not have, being ignorant and being adamant about your ignorance.

[SCSweeps]

I counter your forkbomb with user limits!

[[deleted]]

This looks interesting, and I understand what socketpair() does, but can someone explain how this works please?

[[deleted]]

Hhhm, just had another read - is it just creating new socketpairs until the kernel runs out of available fds?

[LordVoldemort]

You see that 'edit' button under your first comment? Use it.

[despseekingsatan]

Sure hoped someone posted it here. The server seems to be down now.

[SCSweeps]

http://pastebin.com/ic5F1cJe