Weekly Edition
Return to the Press page
| |||||||||||||
New Attack Sneaks Rootkits Into Linux Kernel (Dark Reading)
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).
(Log in to post comments)
A tale of two kernels Posted Apr 15, 2009 18:23 UTC (Wed) by mheily (guest, #27123) [Link]
Compare and contrast:
$ uname
=================== v.s. ====================
$ uname
Re: A tale of two kernels Posted Apr 15, 2009 19:21 UTC (Wed) by gat3way (guest, #47864) [Link]
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] 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 (subscriber, #4563) [Link] 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]
> 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]
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 (subscriber, #2020) [Link]
+1
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]
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]
> 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
New Attack Sneaks Rootkits Into Linux Kernel (Dark Reading) Posted Apr 15, 2009 22:54 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link]
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 (subscriber, #24616) [Link]
> 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] 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]
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 (subscriber, #24616) [Link]
> 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
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] 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 (subscriber, #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]
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
PAX, *BSD, etc. have different opinions, but until we can/want to
Is it not easier to restrict the super user code with SELINUX, capabilities
New Attack Sneaks Rootkits Into Linux Kernel (Dark Reading) Posted Apr 16, 2009 12:10 UTC (Thu) by Trou.fr (subscriber, #26289) [Link]
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 ?
|
|||||||||||||