The details on loading rootkits via /dev/mem

Posted Apr 28, 2009 4:19 UTC (Tue) by spender (guest, #23067)
In reply to: The details on loading rootkits via /dev/mem by Randakar
Parent article: The details on loading rootkits via /dev/mem

Have some hashes:

spender@www:~$ md5sum ./devmem
6c8eb1e89e3e1a8c3bb207eecc517a20 ./devmem
spender@www:~$ sha1sum ./devmem
570b82139714e6640b9b1af02060e51de0558a9c ./devmem
spender@www:~$ date
Mon Apr 27 23:23:29 EDT 2009

See you in a couple years when someone figures it out. Unfortunately there's no one else involved in Linux kernel development who actually cares about improving security. They enjoy the mere appearance of security (the ability to claim they have ASLR and other protections), but don't bother to follow through. And that's why you end up with:

http://www.cr0.org/paper/to-jt-linux-alsr-leak.pdf
http://www.blackhat.com/presentations/bh-europe-09/Fritsc...

These have been public for weeks and are still unfixed. Whoever you think is in charge of the kernel's security is obviously asleep at the wheel.

I hope it's clear to everyone reading that objectivity doesn't matter to you: "I don't know who's correct or who isn't. I don't care." But instead, what's of utmost importance to you is that people "play nice."

Here's a better idea: if you don't have anything technical to offer, don't bother replying. If you know you're out of your element, don't bother replying, or just admit that you don't know what you're talking about. A person who's sitting on an exploit for the subject being discussed is unlikely to change his viewpoint.

-Brad

The details on loading rootkits via /dev/mem

Posted Apr 28, 2009 6:24 UTC (Tue) by nix (subscriber, #2304) [Link] (4 responses)

Um, just checking. This is the person who was castigating the -stable team
for not releasing bugfixes until they could be sure if they were security
holes and they had working exploits, no matter how long it took, *and*
simultaneously that the holes existed in the first place...

... *posting hashes of descriptions of exploits rather than the fix*?!

Any claim you make henceforward that you're interested in *anything* other
than credit (that you're interested in, say, the security of the system or
any reduction in its count of security holes) should be considered in this
light. I'm convinced now.

The details on loading rootkits via /dev/mem

Posted Apr 28, 2009 12:47 UTC (Tue) by spender (guest, #23067) [Link] (3 responses)

You may disagree, but I choose not to contribute in such a way as if the people involved in Linux kernel development acted like other responsible companies who properly handle security. When you have exploits of your own, feel free to share them, but speaking for myself I refuse to support their policy of silently fixing vulnerabilities.

I will continue to do as I have done for the past 8 years and fix these issues within grsecurity. If the kernel developers are as capable as Linus claims to be able to backport silent vulnerability fixes, surely they can spot the fixes in grsecurity as well. The source is available to everyone, after all.

Regarding your summary of my view on how vulnerabilities *known to the developers* in the Linux kernel could better be handled, it's as wrong as it was last year when we corrected you on it. To say that I advocated "not releasing bugfixes until they could be sure if they were security holes and they had working exploits, no matter how long it took" is just pure trolling, and anyone who has read our past posts knows that. If you want to see how it can be handled (a little) better, see Chris Wright's announcement for the latest kernel.

-Brad

The details on loading rootkits via /dev/mem

Posted Apr 28, 2009 13:49 UTC (Tue) by hppnq (guest, #14462) [Link] (2 responses)

Instead you choose to foam at the mouth on a public news website, like, err, other responsible companies.

I am actually interested in your /dev/mem pagetable exploit, by the way. Just curious. Is it a bit like this, or are these people also hopelessly incompetent idiots who need to be taught a lesson?

The details on loading rootkits via /dev/mem

Posted Apr 28, 2009 14:27 UTC (Tue) by spender (guest, #23067) [Link] (1 responses)

If you're referring to this attack in Section 4.2 of the paper:

void remap_kernel_code() {
// Open /dev/mem device
fd = open("/dev/mem", O_RDWR);
// Map kernel code with RW access
// into user address space
user_mem = mmap(0, KERNEL_CODE_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED,fd, KERNEL_CODE_ADDR);
// Overwrite kernel code
memset(user_mem, ATTACK_CODE_ADDR, ATTACK_CODE_SIZE);
}

This is the same method used by the Phalanx2 rootkit which was already discussed above. It's not the method the PaX team and I referred to, which as I've already mentioned needs only use read/write within the first 1MB of /dev/mem, as is allowed by the mainline protection.

But if you're talking about the one in Section 4.1, you're getting warmer.

Though it sounds like the solution provided in Section 5.1 would do the trick against the attacks in Sections 4.1/4.2 as well as our attack, there's also a much easier way to solve all three problems (since in a way, they're all facets of a single problem).

If you do the work to research it, given the details we've already mentioned, I'm pretty confident you can figure out the problem and how to fix it as well.

Completely unrelated, but somewhat "breaking" news: http://kernelbof.blogspot.com/
Hello reliable remote root compromise and disabling of SELinux!
As you can read in the link, this was a vulnerability downplayed as a DoS by Linux vendors (as seems to be the norm these days). Oops.

-Brad

The details on loading rootkits via /dev/mem

Posted Apr 28, 2009 14:39 UTC (Tue) by spender (guest, #23067) [Link]

Also, in case it wasn't clear from the previous post, the "much easier way" to solve the problems referred only to this particular scenario we're discussing with /dev/mem. It should be clear that the protection discussed in the paper is useful against kernel exploitation as well and in fact is quite close to the concept of KERNSEAL which the PaX team came up with in 2003. Google reveals a couple results on KERNSEAL, but the PaX team hasn't released a definitive explanation of the implementation, which is likely why it wasn't referenced by the paper you linked to.

-Brad