Rootkit Resistant Disks Kevin R B Butler Stephen McLaughlin and Patrick D McDaniel Systems and Internet Infrastructure Security Laboratory SIIS Pennsylvania State University University Park PA butler smclaugh mcdaniel cse psu edu ABSTRACT Rootkits are now prevalent in the wild Users affected by rootkits are subject to the abuse of their data and resources often unknowingly Such malware becomes even more dangerous when it is persistent infected disk images allow the malware to exist across reboots and prevent patches or system repairs from being successfully applied In this paper we introduce rootkit resistant disks RRD that label all immutable system binaries and configuration files at installation time During normal operation the disk controller inspects all write operations received from the host operating system and denies those made for labeled blocks To upgrade the host is booted into a safe state and system blocks can only be modified if a security token is attached to the disk controller By enforcing immutability at the disk controller we prevent a compromised operating system from infecting its on disk image We implement the RRD on a Linksys NSLU2 network storage device by extending the I O processing on the embedded disk controller running the SlugOS Linux distribution Our performance evaluation shows that the RRD exhibits an overhead of less than 1 for filesystem creation and less than 1 5 during I O intensive Postmark benchmarking We further demonstrate the viability of our approach by preventing a rootkit collected from the wild from infecting the OS image In this way we show that RRDs not only prevent rootkit persistence but do so in an efficient way Categories and Subject Descriptors D 4 6 Operating Systems Security and Protection General Terms Security Keywords storage security rootkits labels 1 INTRODUCTION Rootkits exploit operating system vulnerabilities to gain control of a victim host For example some rootkits replace the system call Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page To copy otherwise to republish to post on servers or to redistribute to lists requires prior specific permission 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 compounded when such measures are made persistent by modifying the on disk system image e g system binaries and configuration Thus the only feasible way of recovering from a rootkit is to wipe the disk contents and reinstall the operating system 3 13 19 20 Worse still once installed it is in almost all cases impossible to securely remove them The availability of malware and the economic incentives for controlling hosts has made the generation and distribution of rootkits a widespread and profitable activity 44 Rootkit resistant operating systems do not exist today nor are they likely to be available any time soon to address rootkits is to largely solve the general problem of malicious software Current operating system technologies provide better tools than previously available at measuring and governing software 34 but none can make the system impervious to rootkits without placing unreasonable restrictions on their operation However while it is currently infeasible to prevent an arbitrary rootkit from exploiting a given system we observe that preventing them from being becoming persistent is a significant step in limiting both their spread and damage We introduce a rootkit resistant disk RRD that prevents rootkit persistence We build on increasingly available intelligent disk capabilities to tightly govern write access to the system image within the embedded disk processor Because the security policy is enforced at the disk processor rather than in the host OS a successful penetration of the operating system provides no access to modify the system image The RRD works as follows 1 An administrative token containing a system write capability in placed in the USB port of the external hard drive enclosure during the installation of the operating system This ensures that the disk processor has access to the capability but the host CPU does not 2 Associated with every block is a label indicating whether it is immutable Disk blocks associated with immutable system binaries and data are marked during system installation The token is removed at the completion of the installation 3 Any modification of an immutable system block during normal operation of the host OS is blocked by the disk processor 4 System upgrades are performed by safely booting the system with the token placed in the device and the system write capability read and the appropriate blocks marked The token is removed at the completion of the upgrade An RRD superficially provides a service similar to that of liveOS distributions i e images that boot off read only devices such as a CD However an RRD is a significant improvement over such approaches in that a it can intermix and mutable data with immutable data b it avoids the often high overheads of many read only devices and c it permits essential upgrading and patching In short it allows the host to gain the advantages of a tamperresistant system image without incurring the overheads or constraints of read only boot media In this paper we present the design and analysis of the RRD The system architecture implementation and evaluation are detailed and design alternatives that enable performance and security optimizations discussed We implement the RRD on a Linksys NSLU2 network storage device 33 by extending the I O processing on the embedded disk controller and use USB flash memory devices for security tokens Our implementation integrates label and capability management within the embedded software stack SlugOS Linux distribution 50 We further extend the host operating system kernel and installation programs to enable the use of the non standard RRD interfaces and security tokens however in practice modifications to host operating systems will not be needed Our performance evaluation shows that the RRD exhibits small performance and resource overheads The experiments show an overhead of less than 1 for filesystem creation and less than 1 5 during I O intensive Postmark