New Attack Sneaks Rootkits Into Linux Kernel (Dark Reading) [LWN.net]

Dark Reading reports on a "new" way to install rootkits on a Linux system. "At Black Hat Europe this week in Amsterdam, Anthony Lineberry, senior software engineer for Flexilis, will demonstrate how to hack the Linux kernel by exploiting the driver interface to physically addressable memory in Linux, called /dev/mem." Of course, this attack would be blocked by the STRICT_DEVMEM configuration option, introduced into the mainline kernel in 2.6.25 (and by some distributors prior to that).

to post comments

A tale of two kernels

Posted Apr 15, 2009 18:23 UTC (Wed) by mheily (guest, #27123) [Link] (8 responses)

Compare and contrast:

$ uname
OpenBSD
$ man securelevel
...
1 Secure mode
- default mode when system is multi-user
- securelevel may no longer be lowered except by init
- /dev/mem and /dev/kmem may not be written to
...

=================== v.s. ====================

$ uname
Linux
$ man securelevel
No manual entry for securelevel

Re: A tale of two kernels

Posted Apr 15, 2009 19:21 UTC (Wed) by gat3way (guest, #47864) [Link] (2 responses)

Cut this. It's boring already.

Re: A tale of two kernels

Posted Apr 15, 2009 20:03 UTC (Wed) by mheily (guest, #27123) [Link] (1 responses)

Oops, I forgot: the Linux kernel is perfect and is immune to criticism. How ironic that the securelevel LSM module was removed from Linux a few years ago, leaving /dev/mem and /dev/kmem writable by default.

Re: A tale of two kernels

Posted Apr 15, 2009 20:42 UTC (Wed) by luya (subscriber, #50741) [Link]

From this posted link:
"This code has suffered from broken core design and lack of developer
attention. Broken security modules are too dangerous to leave around.
It is time to remove this one."

Trying to trigger Linux/BSD war won't help the cause.

A tale of two kernels

Posted Apr 15, 2009 21:36 UTC (Wed) by ajross (guest, #4563) [Link] (4 responses)

What has happened to this site? This used to be the place I'd come to avoid all the juvenile flaming and have real arguments about real details. There were flames, but informative ones. I used to click on the comments wanting to see what the community had to say. Now as often as not I find this kind of Reddit-style gotcha post staring back at me instead.

It's a pay site, and one that provides good value. And the comments used to be much more valuable than they have since become. That's not a threat, and I'm not about to cancel my subscription. I'm just really not understanding why someone would pay money just to post something like the above comment.

A tale of two kernels

Posted Apr 16, 2009 2:25 UTC (Thu) by PO8 (guest, #41661) [Link]

AFAIK you don't have to pay to post.

A tale of two kernels

Posted Apr 16, 2009 2:42 UTC (Thu) by jake (editor, #205) [Link] (2 responses)

> There were flames, but informative ones.

I actually found the parent to be informative, flamebait, but informative. The later response was even more flamebait-ish, but still had some interesting information (the existence of a securelevel LSM at one point).

I, at least, did not know about either securelevel or its short-lived appearance in the Linux kernel.

Perhaps the parent was trolling, but I don't think *this* particular post shows a major decline in the discourse here. YMMV.

jake

A tale of two kernels

Posted Apr 16, 2009 11:31 UTC (Thu) by interalia (subscriber, #26615) [Link] (1 responses)

What I think the site has lost is the general cordiality. I am quite happy for people to share information about the BSDs, and aspects in which they are better than Linux. But the OP is simply a flamebait way of saying "Linux sucks, BSD is better". The technical information was appreciated, just not the tone. Compare it with times gone past when an equivalent post might have gone along the lines of:

"OpenBSD has a concept of "securelevel", set to level 1 in multiuser, and in which /dev/mem and /dev/kmem may not be written to. The securelevel cannot be subsequently lowered except by init.

Perhaps Linux could consider the same or similar feature?"

Then a discussion might ensue about the merits/drawbacks of such an approach. Just speaking for myself, but that is the kind of posts I like to see. Useful technical info being shared, with people possibly being robust when disagreeing, but still cordial.

A tale of two kernels

Posted Apr 16, 2009 18:01 UTC (Thu) by sjj (guest, #2020) [Link]

It's also not productive to complain that some interface or concept or mechanism (or manpage!) doesn't exist on platform A but exists on platform B with the exact same name.

New Attack Sneaks Rootkits Into Linux Kernel (Dark Reading)

Posted Apr 15, 2009 18:33 UTC (Wed) by jwb (guest, #15467) [Link] (3 responses)

Some guy showed me a /dev/mem rootkit at a 2600 hacker meetup in San Francisco, in 2001. This is anything but new.

The thing to remember is that these rootkits are only installed *after* your box has been compromised. There's nothing about /dev/mem, as far as I know, that allows an ordinary user to escalate his privileges.

New Attack Sneaks Rootkits Into Linux Kernel (Dark Reading)

Posted Apr 15, 2009 22:03 UTC (Wed) by foom (subscriber, #14868) [Link] (2 responses)

> The thing to remember is that these rootkits are only installed *after* your box has been
> compromised.

Such as via an unpatched udev local root compromise? :(

Via Marco d'Itri: "All releases of udev older than 141 allow a local user to instantly get root
privileges (CVE-2009-1185)."

http://www.ubuntu.com/usn/usn-758-1

New Attack Sneaks Rootkits Into Linux Kernel (Dark Reading)

Posted Apr 15, 2009 22:54 UTC (Wed) by jzbiciak (guest, #5246) [Link] (1 responses)

The point is that /dev/mem doesn't allow you to become root. Other things must fail first. If you can become root, you might even be able to replace the kernel bzImage so that the next time the machine reboots, you're integrated into the kernel without the help of /dev/mem.

New Attack Sneaks Rootkits Into Linux Kernel (Dark Reading)

Posted Apr 16, 2009 9:06 UTC (Thu) by hppnq (guest, #14462) [Link]

The puprpose of a rootkit is to remain unnoticed after gaining root privileges. Replacing the kernel image may, for various reasons, not always be successful and should be far easier to detect than a running kernel that was patched through /dev/mem.

New Attack Sneaks Rootkits Into Linux Kernel (Dark Reading)

Posted Apr 16, 2009 2:07 UTC (Thu) by eteo (guest, #36711) [Link]

This is hardly new. There are public rootkits that used this long ago.

New Attack Sneaks Rootkits Into Linux Kernel (Dark Reading)

Posted Apr 16, 2009 8:57 UTC (Thu) by PaXTeam (guest, #24616) [Link] (10 responses)

> Of course, this attack would be blocked by the STRICT_DEVMEM configuration option

of course it would not.

New Attack Sneaks Rootkits Into Linux Kernel (Dark Reading)

Posted Apr 16, 2009 9:30 UTC (Thu) by hppnq (guest, #14462) [Link] (5 responses)

I am confused by your "of course".

Do you mean that a feature that can be turned on can also be turned off? Or do you mean that the attack as described in the paper would work even if access to /dev/mem is restricted through STRICT_DEVMEM?

New Attack Sneaks Rootkits Into Linux Kernel (Dark Reading)

Posted Apr 16, 2009 9:50 UTC (Thu) by nye (guest, #51576) [Link] (1 responses)

My completely uninformed guess would be that an attacker who is already root (as is necessary here) could insert their own kernel module to do an end run around this protection (and then remove it once done).

New Attack Sneaks Rootkits Into Linux Kernel (Dark Reading)

Posted Apr 16, 2009 9:52 UTC (Thu) by nye (guest, #51576) [Link]

I probably should have thought a little more before posting that really, of course module insertion is specifically what this attack is trying to avoid. :P

New Attack Sneaks Rootkits Into Linux Kernel (Dark Reading)

Posted Apr 16, 2009 11:15 UTC (Thu) by PaXTeam (guest, #24616) [Link] (2 responses)

> I am confused by your "of course".

sorry, it's just an inside jibe for the security community that follows such 'security' features ;).

> Or do you mean that the attack as described in the paper would work even
> if access to /dev/mem is restricted through STRICT_DEVMEM?

well, obviously it can't be 'as described' as the paper doesn't talk about circumventing this feature, but the generic attack technique of abusing /dev/mem is not blocked by STRICT_DEVMEM. just look at what the code actually does and you'll see.

New Attack Sneaks Rootkits Into Linux Kernel (Dark Reading)

Posted Apr 16, 2009 13:34 UTC (Thu) by hppnq (guest, #14462) [Link] (1 responses)

You still confuse me. :-)

The article describes a manipulation of the system call table through /dev/mem, and states explicitly that STRICT_DEVMEM provides protection against the described attack. Skimming through the code in the paper, I fail to see how STRICT_DEVMEM can be circumvented, since, as you observe, the attack does not try to circumvent it. There are of course ways to do it, but surely not through /dev/mem?

New Attack Sneaks Rootkits Into Linux Kernel (Dark Reading)

Posted Apr 16, 2009 19:46 UTC (Thu) by PaXTeam (guest, #24616) [Link]

i see where your confusion comes from, sorry about it. i talked about the STRICT_DEVMEM code itself, not anything in the paper.

New Attack Sneaks Rootkits Into Linux Kernel (Dark Reading)

Posted Apr 16, 2009 9:31 UTC (Thu) by k3ninho (subscriber, #50375) [Link] (1 responses)

I note the name and expect that you know enough to supply more detail. I'm curious: why would it not be blocked?

New Attack Sneaks Rootkits Into Linux Kernel (Dark Reading)

Posted Apr 16, 2009 9:54 UTC (Thu) by cate (subscriber, #1359) [Link]

I think it is because of different definition of *this* (in this attack).
But considering also the first troll, the question is:
Should Linux kernel should protect programs only from bad/malicious user
programs/daemons, or also from the super user programs?

In linux we have: /sbin/shutdown, ability to install new kernels, and new
programs (also system programs), so super user has still enough power, that
such discussion about some extra way to destroy system seems to me
senseless.

PAX, *BSD, etc. have different opinions, but until we can/want to
install/upgrade new software we have larger attack vectors.

Is it not easier to restrict the super user code with SELINUX, capabilities
and good user/group management, than to hack kernel interface?

New Attack Sneaks Rootkits Into Linux Kernel (Dark Reading)

Posted Apr 16, 2009 12:10 UTC (Thu) by Trou.fr (subscriber, #26289) [Link] (1 responses)

the article itself say it is sufficient to block the attack. STRICT_DEVMEM prevents access above 1 MB of RAM, which is exactly the place where the kernel is mapped.

I guess we're missing something here to understand your claim.

New Attack Sneaks Rootkits Into Linux Kernel (Dark Reading)

Posted Apr 16, 2009 12:35 UTC (Thu) by Trou.fr (subscriber, #26289) [Link]

Answering to myself : looking at http://wiki.osdev.org/Memory_Map_(x86), I can see potential ways :
- realmode IVT (i don't know if Linux ever gets back to real mode though)
- BIOS code shadow
- mappings @ 0xC8000 ?