LWN.net Logo

The details on loading rootkits via /dev/mem

The details on loading rootkits via /dev/mem

Posted Apr 23, 2009 8:15 UTC (Thu) by const-g (subscriber, #5006)
In reply to: The details on loading rootkits via /dev/mem by spender
Parent article: The details on loading rootkits via /dev/mem

You wrote:

"There are a number of different approaches, but the most obvious is to simply modify the page table entry associated with the virtual address the attacker is attempting to modify. To do this, a review of the code of set_pte_vaddr and the exported swapper_pg_dir symbol would be of use. If you actually knew as much as you think you know, I wouldn't have to generate these scenarios for you."

This is what I meant when I wrote in my first post:

"Of course if module interface is available, one can load a malicious code that can set arbitrary memory as both writable and executable. There are even (usually un-exported but obtainable via System.map or /proc/kallsyms) kernel functions that will do it for you. Using module interface is much more practical to achieve the result described in the article."

Or are you claiming that you know of a "trick" to change page tables permissions by using io on /dev/mem (without mmap)?

I do not think /dev/mem has much longer to live. The drivers (Xorg) are encouraged to use /sys/.../resource files to map what they need and the need for /dev/mem will be eventually gone.

[root@constg ~]# pidof Xorg
2702
[root@constg ~]# cat /proc/2702/maps | grep /sys
a7fc4000-b7fc4000 rw-s e0000000 00:00 6798 /sys/devices/pci0000:00/0000:00:02.0/resource2
b7fc4000-b8044000 rw-s f8080000 00:00 6797 /sys/devices/pci0000:00/0000:00:02.0/resource0
b8044000-b80c4000 rw-s f8000000 00:00 6797 /sys/devices/pci0000:00/0000:00:02.0/resource0


(Log in to post comments)

The details on loading rootkits via /dev/mem

Posted Apr 23, 2009 12:52 UTC (Thu) by spender (subscriber, #23067) [Link]

You keep revising what you "meant" to say (forgetting the self-sufficient sentences that are just factually wrong, which no ex post facto revising can fix), and again your revisions are completely wrong.

You say "Of course if module interface is available, one can load a malicious code that can set arbitrary memory as both writable and executable."

Wrong again; module support isn't necessary to set arbitrary memory as both writable and executable. And yes, it can be done purely with read() and write() on /dev/mem as I've already said. You can call it a "trick" if you like, but if you did the reading I suggested it would be simply "textbook behavior."

Since you're clearly unwilling to educate yourself, there's no point really in wasting any more time with this.

-Brad

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds