Administrators like to know what processes are running on their machines, with good reason as they are responsible for ensuring that no unwanted or malicious software is present. Rootkits are a means of evading administrators, hiding the presence and the execution of certain programs. Probably the most famous rootkit is the one that Sony so helpfully installed on Windows boxes when their owners tried to play a copy-protected audio CD, but they exist for Linux as well. It is critical for administrators to understand what rootkits can do and how they do it in order to protect their systems against this kind of attack.
Rootkits come in multiple flavors, depending on what level of the system they subvert. The simplest just replace binaries of various programs to hide; for example, running a backdoor shell server masquerading as a standard long-running service (like httpd or ntpd) and patching netstat and other tools so that the listening socket is not reported. System libraries are another likely place for rootkits.. If a rootkit can replace glibc, it can intercept system calls made by any of the standard tools allowing it to hide anything that it chooses from those tools.
Kernel and boot rootkits are the most difficult to detect. Loadable kernel modules can change the kernel's behavior in very intrusive ways and allow all manner of malware to run undetected. The lowest level rootkit changes the Master Boot Record (MBR) of the system to load itself before the kernel at boot time. After that the rootkit can run the kernel in a virtual machine and intercept every instruction that it executes. This is the ultimate in rootkits and can be made undetectable from within the running kernel.
Trying to detect a rootkit installation while running the potentially infected system is a dodgy prospect at best. Because the rootkit is specifically designed to avoid detection it could be subverting any technique used to look for it. The important thing to notice is that in order to operate, the rootkit must change things about the system and in order to persist across reboots, it must write those changes to the disk. This provides the means to detect them.
To avoid running afoul of the rootkit while trying to detect it, one should boot from a live CD and run a rootkit detector from there. There are a number of distributions specifically targeted for this kind of analysis; Helix and Aghesa for example. Both of those distributions contain the two leading Linux rootkit detecting programs: chkrootkit and Rootkit Hunter. These programs look for things in the filesystem that correspond to rootkit signatures: hidden files and directories, logfile changes, non-standard kernel modules, etc. In addition they look for the signature of various 'in the wild' rootkits.
Another helpful tool in recognizing the presence of rootkits are programs that track changes to critical files and directories. The most well known is probably Tripwire, but others such as AIDE and Samhain are available as well. These programs keep a record of each file in the system (using a digest like MD5 or SHA-1) and can alert the administrator when one of them changes. They also keep track of files and directories that get added or deleted. Prudent administrators will, of course, keep the records on a separate machine or on read-only media so that they cannot be tampered with by rootkits that infect the machine. The biggest problem with these kinds of programs is false positives each time a new package is installed, but for relatively static systems, an alert email from those checkers is an enormous red flag.
A very interesting sounding rootkit detection toolkit called Rootkit Profiler LX was recently announced on the Bugtraq mailing list. It is a linux kernel module that gets loaded into the running kernel of a machine suspected of harboring a rootkit and has an impressive sounding list of capabilities. It is not available in source form which makes it of dubious utility; it could after all, be a rootkit itself. One could argue that using binaries from the live CDs is no different, and in some ways that is true, but one could in principle inspect the code and build their own version rather than trusting the distributor (of course they have to trust their compiler and other components; security paranoia can run deep).
Once a rootkit has been detected, it is probably a waste of time to try and remove it. Reinstalling the operating system is the safest course. The time spent trying to remove every last piece of the rootkit and the malware it hides would be better spent determining how the rootkit was installed to begin with. If there is a vulnerability in one of the programs that run on that machine, it is pretty likely the rootkit (or some other) will return. Of course, the rootkit, in and of itself, is not a huge problem; it is the malware that it hides that makes all the trouble.
|Created:||February 27, 2007||Updated:||February 28, 2007|
|Description:||When certain CHM files that contain tables and objects stored in pages are parsed by CHMlib, an unsanitized value is passed to the alloca() function resulting in a shift of the stack pointer to arbitrary memory locations. An attacker could entice a user to open a specially crafted CHM file, resulting in the execution of arbitrary code with the permissions of the user viewing the file.|
|Created:||February 23, 2007||Updated:||February 28, 2007|
|Description:||Mikhail Markin reported that enigmail incorrectly handled memory allocations for certain large encrypted attachments. This caused Thunderbird to crash and thus caused the entire message to be inaccessible.|
|Created:||February 23, 2007||Updated:||November 14, 2007|
|Description:||The Linux kernel before 18.104.22.168 allows remote attackers to cause a denial of service (oops) via a crafted NFSACL 2 ACCESS request that triggers a free of an incorrect pointer.|
|Package(s):||seamonkey firefox thunderbird||CVE #(s):||CVE-2006-6077 CVE-2007-0008 CVE-2007-0009 CVE-2007-0775 CVE-2007-0777 CVE-2007-0778 CVE-2007-0779 CVE-2007-0780 CVE-2007-0800 CVE-2007-0981 CVE-2007-0995 CVE-2007-0996|
|Created:||February 26, 2007||Updated:||July 23, 2007|
|Description:||Several flaws were found in the way SeaMonkey processed certain malformed
a way that may result in SeaMonkey crashing or executing arbitrary code as
the user running SeaMonkey. (CVE-2007-0775, CVE-2007-0777)
Several cross-site scripting (XSS) flaws were found in the way SeaMonkey processed certain malformed web pages. A malicious web page could display misleading information which may result in a user unknowingly divulging sensitive information such as a password. (CVE-2006-6077, CVE-2007-0995, CVE-2007-0996)
A flaw was found in the way SeaMonkey cached web pages on the local disk. A malicious web page may be able to inject arbitrary HTML into a browsing session if the user reloads a targeted site. (CVE-2007-0778)
A flaw was found in the way SeaMonkey displayed certain web content. A malicious web page could generate content which could overlay user interface elements such as the hostname and security indicators, tricking a user into thinking they are visiting a different site. (CVE-2007-0779)
Two flaws were found in the way SeaMonkey displayed blocked popup windows. If a user can be convinced to open a blocked popup, it is possible to read arbitrary local files, or conduct an XSS attack against the user. (CVE-2007-0780, CVE-2007-0800)
Two buffer overflow flaws were found in the Network Security Services (NSS) code for processing the SSLv2 protocol. Connecting to a malicious secure web server could cause the execution of arbitrary code as the user running SeaMonkey. (CVE-2007-0008, CVE-2007-0009)
A flaw was found in the way SeaMonkey handled the "location.hostname" value during certain browser domain checks. This flaw could allow a malicious web site to set domain cookies for an arbitrary site, or possibly perform an XSS attack. (CVE-2007-0981)
|Package(s):||nexuiz||CVE #(s):||CVE-2006-6609 CVE-2006-6610|
|Created:||February 26, 2007||Updated:||February 28, 2007|
|Description:||Nexuiz fails to correctly validate input within "clientcommands". There is also a failure to correctly handle connection attempts from remote hosts. Using a specially crafted "clientcommand" a remote attacker can cause a buffer overflow in Nexuiz which could result in the execution of arbitrary code. Additionally, there is a Denial of Service vulnerability in Nexuiz allowing an attacker to cause Nexuiz to crash or to run out of resources by overloading it with specially crafted connection requests.|
|Created:||February 22, 2007||Updated:||September 4, 2012|
|Description:||The slocate permission checking code has a local information disclosure vulnerability. During the reporting of matching files, slocate does not respect the parent directory's read permissions, resulting in hidden filenames being viewable by other local users.|
|Package(s):||ufo2000||CVE #(s):||CVE-2006-3788 CVE-2006-3789 CVE-2006-3790 CVE-2006-3791 CVE-2006-3792|
|Created:||February 26, 2007||Updated:||February 28, 2007|
|Description:||Five vulnerabilities were found: a buffer overflow in recv_add_unit(); a problem with improperly trusting user-supplied string information in decode_stringmap(); several issues with array manipulation via various commands during play; an SQL injection in server_protocol.cpp; and finally, a second buffer overflow in recv_map_data().|
Page editor: Jonathan Corbet
Next page: Kernel development>>
Copyright © 2007, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds