Linode Kernel Exploits leading to Host Access

@caker:

Kernel 2.4.24-linode19-1um brings us up to date with the latest Linux kernel version (2.4.24 changelog) which contains a local root exploit fix (details here and here), and also brings us up to date with the latest UML patch (2.4.23-1um).
disclaimer: this is a question :)

This is how I understand the linode setup..

host->linode kernel (this process on the host)->your linode.

so it wouldn't be safe to allow modules inserted into a linode's kernel as they would basically be executing code on the host machine..

http://isec.pl/vulnerabilities/isec-0013-mremap.txt says:
> Impact:

=======

Since no special privileges are required to use the mremap(2) system

call any process may misuse its unexpected behavior to disrupt the kernel

memory management subsystem. Proper exploitation of this vulnerability may

lead to local privilege escalation including ****execution of arbitrary code

with kernel level access****. Proof-of-concept exploit code has been created

and successfully tested giving UID 0 shell on vulnerable systems.
If I understand this correctly, this can lead back up to the host machine since it is allows "execution of arbitrary code with kernel level access".. right?

Kenny

5 Replies

I asked this in a far more simple way in his original thread, but no reply :(

I guess Chris would have realised and patched for such a major thing if it were exploitable.

@Quik:

I asked this in a far more simple way in his original thread, but no reply :(

I guess Chris would have realised and patched for such a major thing if it were exploitable.

I think that you are right. If there was a kernel exploit which allowed the execution of arbitrary code in the kernel, then this exploit could be used by a Linode to run arbitrary code as the user that runs the Linode on the host. Given that the same bug (or other bugs, known or unknown) might allow a local user on the host to get root, then this is potentially a vulnerability for the entire Linode host.

@Quik:

I asked this in a far more simple way in his original thread, but no reply :(

I guess Chris would have realised and patched for such a major thing if it were exploitable.
@Quik:

Do the host machines need to be upgraded to this too?

I thought you were asking about the host machine's kernel. If it works how I think it does, then just having vulnerable linode kernels available is a risk to the host machine… of course it probably doesn't work how I think it does :)

kenny

I think there is a good chance that if the UML is vulnerable, that the host would be exposed. I don't believe exploits designed for an i386 kernel would have the desired effect if ran from within UML, but it's not that far off that someone could customize an exploit to de-virtualize the addressing of the UML's memory stack, and modify the exact memory location on the host where it needs it…

I'll be putting a box here locally through some tests and should know more by tomorrow.

On a related topic, I've trimmed the list of available kernels down to ones that aren't vulnerable (with the exception of the djc kernel, which I'll be updating shortly). I also keyed config profiles to point to Latest 2.4 if you were pointing to one of the older kernels.

-Chris

Any chance the updated djc kernel will still have freeswan in it? I still really need ipsec.

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct