Anthony Lineberry on /dev/mem Rootkits
At Black Hat Europe in mid-April 2009, Anthony Lineberry presented an interesting paper on how attackers with root privileges might use a /dev/mem rootkit, hiding their attacks by directly altering kernel memory. Although not a completely new technique, Anthony's BHE presentation put it back in the spotlight. In addition, Lineberry described proof-of-concept tools he's developing to demonstrate how this technique could be exploited in the real world.
On the one hand, once attackers have gained root privileges on your system, it's game over—the attackers have complete control, and all hope for further defense and mitigation on your part is gone. Looked at from that viewpoint, the attackers' ability to write directly to kernel memory isn't too radically different from, or worse than, other things they can do as root.
But, on the other hand, even if your system suffers root compromise, you still want some chance of at least detecting the compromise in order to do something about it. Because the purpose of rootkits is to prevent that, it behooves you to take whatever precautions you can against them. So in this sense, new rootkit techniques actually are very worthy of our attention and concern.
In this article, I provide some background on rootkits and /dev/mem, and Anthony Lineberry sheds further light on /dev/mem rootkits, in the form of a conversation we recently had.
So, what exactly is a rootkit? Simply put, a rootkit is hostile code that conceals or misrepresents a system's state, as presented to its administrator.
The “kit” part of the term reflects the fact that early UNIX rootkits took the form of collections of one-for-one replacements of system commands, such as ls and ps. The replacement commands behaved, for the most part, like the commands they replaced, except they were selectively blind. A rootkit's ls command, for example, might omit the attacker's directory /...my_evil_tools in file listings it displays, and a rootkit's ps command might omit the attacker's program erase_recent_logs from process listings. In other words, rootkits are designed to conceal the activities of system attackers once they've achieved a foothold on a target system.
One problem with first-generation rootkits was that their functionality was limited to those specific commands replaced by rootkit versions. What if the system administrator used some command or utility rather than ls to view the contents of a directory containing attack evidence?
Another problem was detectability. If a system is protected with system integrity software like Tripwire, which detects and reports on authorized changes to system files, it can be difficult to replace system commands without being detected.
Both these problems were largely “solved” with the advent of Loadable Kernel Module (LKM) rootkits. An LKM rootkit, as the name implies, consists of one or more kernel modules loaded by attacks. An LKM rootkit re-maps the actual system calls (also known as kernel symbols) accessed by system utilities, leaving the system commands themselves unchanged. Needless to say, this is a very powerful technique.
As powerful as LKM rootkits still are, they nonetheless can be detected, for example, by comparing the kernel's system map (a file showing the correct memory addresses of all supported system calls) with the actual system call addresses in memory. On a non-LKM-infested system, those addresses should be the same as in the system map.
That, then, is the problem space in which rootkits operate—concealing attack activity and results in a way that is not itself conspicuous. But, what is /dev/mem, and how is this particular kernel interface different from an LKM?
/dev/mem is a character device that provides root-privileged processes in userspace (that is, programs other than the kernel or kernel modules) direct access to physical memory. /dev/kmem is the same thing, but it uses “virtual” memory addresses like the kernel uses rather than the “raw” addresses of physical memory. Unlike /proc/kcore, which serves a similar function to developers and kernel hackers, /dev/mem and /dev/kmem grant not only read access, but also write access to memory.
You might be forgiven for assuming that, like /dev/eth0, /dev/hda and other special files in /dev, /dev/mem is an essential interface for userspace applications that need to communicate with the kernel. As it happens, this isn't necessarily the case. Besides kernel developers, historically, the other major user of /dev/mem is the X Window System, parts of which still use /dev/mem to access video adapters' memory and control registers.
At least in the case of /dev/kmem, some people think these particular devices are of greater use to attackers than for more legitimate purposes. As far back as 2005, Jonathan Corbet of lwn.net said, “It has been suggested that rootkits are the largest user community for this kind of access” (see Resources for the full context; he was speaking specifically of /dev/kmem).
Hopefully, I'm not overstating this case, because being neither a kernel developer nor an X Windows System expert, I would not presume to argue for abolishing /dev/mem or /dev/kmem myself. Rather, I'm trying to put all of this into a useful context—which brings us to Anthony Lineberry.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Nice article, thanks for the
7 hours 51 min ago
- I once had a better way I
13 hours 37 min ago
- Not only you I too assumed
13 hours 54 min ago
- another very interesting
15 hours 47 min ago
- Reply to comment | Linux Journal
17 hours 41 min ago
- Reply to comment | Linux Journal
1 day 35 min ago
- Reply to comment | Linux Journal
1 day 51 min ago
- Favorite (and easily brute-forced) pw's
1 day 2 hours ago
- Have you tried Boxen? It's a
1 day 8 hours ago
- seo services in india
1 day 13 hours ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?