The details on loading rootkits via /dev/mem
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
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
Posted Apr 28, 2009 5:40 UTC (Tue)
by patrick_g (subscriber, #44470)
[Link]
Posted Apr 28, 2009 6:24 UTC (Tue)
by nix (subscriber, #2304)
[Link] (4 responses)
... *posting hashes of descriptions of exploits rather than the fix*?!
Any claim you make henceforward that you're interested in *anything* other
Posted Apr 28, 2009 12:47 UTC (Tue)
by spender (guest, #23067)
[Link] (3 responses)
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
Posted Apr 28, 2009 13:49 UTC (Tue)
by hppnq (guest, #14462)
[Link] (2 responses)
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?
Posted Apr 28, 2009 14:27 UTC (Tue)
by spender (guest, #23067)
[Link] (1 responses)
void remap_kernel_code() {
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/
-Brad
Posted Apr 28, 2009 14:39 UTC (Tue)
by spender (guest, #23067)
[Link]
-Brad
>>> Whoever you think is in charge of the kernel's security is obviously asleep at the wheel.The details on loading rootkits via /dev/mem
Linux development is open. If nobody is in charge of the kernel's security why don't you take in charge this role? Of course you must learn to interact well with other in the community but patchs are very welcome.
The details on loading rootkits via /dev/mem
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...
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
Instead you choose to foam at the mouth on a public news website, like, err, other responsible companies.
The details on loading rootkits via /dev/mem
The details on loading rootkits via /dev/mem
// 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);
}
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.
The details on loading rootkits via /dev/mem