|Linux Kernel Rootkits|
To get a list of kernel modules, two standard methods can be used:
bash$ lsmod bash$ cat /proc/modules
In addition, one can look at the list of symbols exported by modules (/proc/ksyms), where the name of the corresponding module will be listed in square brackets, like the following symbol exported from the snd (sound) module:
c85029f4 snd_task_name [snd]
Unfortunately, being a kernel module, an LKM rootkit can easily defeat such efforts by a variety of methods. Fortunately, there is a better way to detect an LKM rootkit:
In order to replace kernel syscalls with their own code, LKM rootkits modify the table which holds the addresses of these syscalls, to point to the module's replacement function instead of the original kernel function. Now, whenever a kernel is compiled, a map of kernel symbols and their respective addresses in the kernel is generated. This map is called System.map (sometimes with the kernel version appended), and usually install in the same location as the kernel (e.g. /boot). Thus, a straightforward way to detect hijacked kernel syscalls is to compare this map against the actual addresses of all syscalls, which will show all syscalls whose address is different from the original address listed in the map.
This is a non-exhaustive list of programs that are useful for the detection of kernel modifications in a running system.
kern_check.c is a small command-line utility (for Linux 2.2.x, 2.4.x) that will compare your System.map against your kernels syscall table and warn about any inconsistencies (PGP signature kern_check.c.asc).
bash$ gpg --verify kern_check.c.asc kern_check.c bash$ gcc -O2 -Wall -o kern_check kern_check.c bash$ su bash$ kern_check /path/to/System.map
This will only detect rootkits that modify the syscall table directly. In particular, it will not detect the SucKIT rootkit (see Section 2.2>).
CheckIDT, published in Phrack issue 59, article 0x04 ("Handling the Interrupt Descriptor Table", by kad) is a utility that can be used to list the Interrupt Descriptor Table (IDT) (see Section 2.2>) and save the current state to check its integrity later on. Currently there is no published real rootkit that uses the IDT, only proof-of-concept code.