New Attack Sneaks Rootkits Into Linux Kernel

[dragonbite]

From
http://www.darkreading.com/security/vulnerabilities/showArticle.jhtml?articleID=216500687 (http://www.darkreading.com/security/vulnerabilities/showArticle.jhtml?articleID=216500687)

[aleph]

$ ls -l /dev/mem
crw-r----- 1 root kmem 1, 1 04-15 10:51 /dev/mem


One still needs root access (writing to /dev/mem) to plant this rootkit.

[dragonbite]

$ ls -l /dev/mem
crw-r----- 1 root kmem 1, 1 04-15 10:51 /dev/mem


One still needs root access (writing to /dev/mem) to plant this rootkit.

Wouldn't installing, through yum, grant it root access?

Also, how does SELinux handle this?

[aleph]

Wouldn't installing, through yum, grant it root access?

Also, how does SELinux handle this?

It's a proof-of-concept rootkit created for research purposes. Nobody has actually put it in released kernel code. I think they did it so to warn the kernel/distro maintainers not to allow something like that happening.

How does SELinux handle this? Depends on how a distro manages its SELinux policies. Haven't dug into Fedora's though :cool:

[domg472]

Found 10 semantic av rules:
allow hald_mac_t memory_device_t : chr_file { ioctl read write getattr lock append open } ;
allow rpm_t memory_device_t : chr_file { ioctl read getattr lock open } ;
allow hald_t memory_device_t : chr_file { ioctl read getattr lock open } ;
allow initrc_t memory_device_t : chr_file { ioctl read write getattr lock append execute open } ;
allow vmware_t memory_device_t : chr_file { ioctl read write getattr lock append open } ;
allow kudzu_t memory_device_t : chr_file { ioctl read write getattr lock append execute open } ;
allow xserver_t memory_device_t : chr_file { ioctl read write getattr lock append execute open } ;
allow klogd_t memory_device_t : chr_file { ioctl read getattr lock open } ;
allow dmidecode_t memory_device_t : chr_file { ioctl read getattr lock open } ;
allow vbetool_t memory_device_t : chr_file { ioctl read write getattr lock append execute open } ;


Obviously root in the unconfined_t domain has full access to the system.
RPM runs as root in a unconfined domain.
Initrc_t also runs as root in a unconfined domain

So be careful what you install. Keep in mind that vmware for example can write to it.
Want to minimize risk? de-install the unconfined selinux module, map your users to confined user domains, if you can de-install as many of the programs listed above.

[adrianx]

Linux system administrators typically aren't aware of the potential dangers of leaving /dev/mem exposed. Lineberry says his goal is to educate them on this potential security hole. And there's now a way to defend against such an attack, too: the Linux development community recently issued a patch to locks down /dev/mem, limiting read and write access from the outside, he says.
Luckily, it's not just all doom and gloom.... :)