The details on loading rootkits via /dev/mem

Posted Apr 28, 2009 6:24 UTC (Tue) by nix (subscriber, #2304)
In reply to: The details on loading rootkits via /dev/mem by spender
Parent article: The details on loading rootkits via /dev/mem

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