Rootkit-Resistant DisksKevin R. B. Butler, Stephen McLaughlin and Patrick D. McDanielSystems and Internet Infrastructure Security Laboratory (SIIS)Pennsylvania State University, University Par k, PA{butler,smclaugh,mcdaniel}@cse.psu.eduABSTRACTRootkits are now prevalent in the wild. Users affected by rootk-its are subject to the abuse of their data and resources, often un-knowingly. Such malware becomes even more dangerous when itis persistent–infected disk images allow the malware to exist acrossreboots and prevent patches or system repairs from being success-fully applied. In this paper, we introduce rootkit-resistant disks(RRD) that label all immutable system binaries and configurationfiles at installation time. During normal operation, the disk con-troller inspects all write operations received from the host operat-ing system and denies those made for labeled blocks. To upgrade,the host is booted into a safe state and system blocks can only bemodified if a security token is attached to the disk controller. Byenforcing immutability at the disk controller, we prevent a compro-mised operating system from infecting its on-disk image.We implement the RRD on a Linksys NSLU2 network storagedevice by extending the I/O processing on the embedded disk con-troller running the SlugOS Linux distribution. Our performanceevaluation shows that the RRD exhibits an overhead of less than1% for filesystem creation and less than 1.5% during I/O intensivePostmark benchmarking. We further demonstrate the viability ofour approach by preventing a rootkit collected from the wild frominfecting the OS image. In this way, we show that RRDs not onlyprevent rootkit persistence, but do so in an efficient way.Categories and Subject DescriptorsD.4.6 [Operating Systems]: Security and ProtectionGeneral TermsSecurityKeywordsstorage, security, rootkits, labels1. INTRODUCTIONRootkits exploit operating system vulnerabilities to gain control ofa victim host. For example, some rootkits replace the system callPermission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.CCS’08, October 27–31, 2008, Alexandria, Virginia, USA.Copyright 2008 ACM 978-1-59593-810-7/08/10 ...$5.00.table with pointers to malicious code. The damage is compoundedwhen such measures are made persistent by modifying the on-disksystem image, e.g., system binaries and configuration. Thus, theonly feasible way of recovering from a rootkit is to wipe the diskcontents and reinstall the operating system [3, 13, 19, 20]. Worsestill, once installed, it is in almost all cases impossible to securelyremove them. The availability of malware and the economic incen-tives for controlling hosts has made the generation and distributionof rootkits a widespread and profitable activity [44].Rootkit-resistant operating systems do not exist today, nor arethey likely to be available any time soon; to address rootkits is tolargely solve the general problem of malicious software. Currentoperating system technologies provide better tools than previouslyavailable at measuring and governing software [34], but none canmake the system impervious to rootkits without placing unreason-able restrictions on their operation. However, while it is currentlyinfeasible to prevent an arbitrary rootkit from exploiting a givensystem, we observe that preventing them from being becoming per-sistent is a significant step in limiting both their spread and damage.We introduce a rootkit-resistant disk (RRD) that prevents rootkitpersistence. We build on increasingly available intelligent disk ca-pabilities to tightly govern write access to the system image withinthe embedded disk processor. Because the security policy is en-forced at the disk processor (rather than in the host OS), a suc-cessful penetration of the operating system provides no access tomodify the system image. The RRD works as follows:1. An administrative token containing a system write capabilityin placed in the USB port of the external hard drive enclosureduring the installation of the operating system. This ensuresthat the disk processor has access to the capability, but thehost CPU does not.2. Associated with every block is a label indicating whether itis immutable. Disk blocks associated with immutable systembinaries and data are marked during system installation. Thetoken is removed at the completion of the installation.3. Any modification of an immutable system block during nor-mal operation of the host OS is blocked by the disk processor.4. System upgrades are performed by safely booting the systemwith the token placed in the device (and the system write ca-pability read), and the appropriate blocks marked. The tokenis removed at the completion of the upgrade.An RRD superficially provides a service similar to that of “live-OS” distributions, i.e., images that boot off read-only devices suchas a CD. However, an RRD is a significant improvement over suchapproaches in that (a) it can intermix and mutable data with im-mutable data, (b) it avoids the often high overheads of many read-only devices, and (c) it permits (essential) upgrading and patch-ing. In short, it allows the host to gain the advantages of a tamper-resistant system image without incurring the overheads or constraintsof read-only boot media.In this paper, we present the design and analysis of the RRD. Thesystem architecture, implementation, and evaluation are detailedand design alternatives that enable performance and security opti-mizations discussed. We implement the RRD on a Linksys NSLU2network storage device [33] by extending the I/O processing on theembedded disk controller, and use USB flash memory devices forsecurity tokens. Our implementation integrates label and capabilitymanagement within the embedded software stack (SlugOS Linuxdistribution [50]). We further extend the host operating system ker-nel and installation programs to enable the use of the non-standardRRD interfaces and security tokens: however, in practice, modifi-cations to host operating systems will not be needed.Our performance evaluation shows that the RRD exhibits smallperformance and resource overheads. The experiments show anoverhead