New Linux rootkit technique presented

Anthony Lineberry, a Linux expert, announced during his presentation, "Alice in User-Land: Hijacking the Linux Kernel via /dev/mem", at the Black Hat security conference now taking place in Amsterdam that he will shortly be publishing the libmemrk library. He says Libmemrk works in both 32-bit and 64-bit environments.
This offers rootkit developers a new way to hide files or processes, or interfere with network traffic. The trick is that, without requiring extensive rights, libmemrk uses the /dev/mem device driver to write arbitrary code from userspace into main memory. /dev/mem is an interface that enables use of the physically addressable memory. For example XServer and DOSEmu, both use it. Lineberry says introducing rootkits via /dev/mem is also less obvious than the established route via loadable kernel modules (LKMs).


The library relieves a rootkit programmer of the "laborious" work of translating virtual memory addresses to physical ones and identifying a memory range that can be exploited for the attack. An attacker can't overwrite the existing system calls and replace them with his own code until the suitable ranges, normally used by the kernel, have been located. The real contents written into memory by the kernel are meanwhile shifted into a buffer.

The detailed steps required for a successful attack, which are handled by libmemrk, are described by Lineberry in his white paper, Malicious Code Injection via /dev/mem. However, Lineberry states there that an attack fails in virtual environments because the hypervisor behaves differently from unvirtualised hardware. Lineberry asks his audience to bear in mind that, regardless of libmemrk, the whole attack must be hand-programmed in assembly language. In future, Lineberry intends that libcc will be used in order to at least reduce the impact of this hurdle.

Lineberry also gives some tips on how the Linux world can protect itself against rootkits of this kind. He believes it should be enough to modify the memory driver so that it doesn't allow the write/read pointer lseek to look for more than 16 kilobytes in the memory area. Current versions of Red Hat and Fedora are inherently secure, because their kernel already incorporates the features of SELinux (Security Enhanced Linux).
Lineberry says there are also corresponding improvements in version 2.6.26 of the mainline kernel. For that purpose, the kernel was given two new functions: range_is_allowed() and devmem_is_allowed(). But this protection, he says, won't be effective unless the preprocessor directive CONFIG_STRICT_DEVMEM has been enabled when the kernel is compiled. Otherwise, range_is_allowed() always gives returns success. Lineberry says that the kernel configuration setting STRICT_DEVMEM, which sets CONFIG_STRICT_DEVMEM, is not activated by default during kernel compilation. He was unable to say when libmemrk would be available for downloading, as he was still engaged in eliminating its last weaknesses.


The technique of using the /dev/mem interface is not totally new. An article on Linux on-the-fly kernel patching without LKM appeared in Phrack back in 2001, describing a similar method using /dev/kmem/. The authors were already thinking about possible uses for /dev/mem then, but didn't go on to check them out.