������� ��� �������� �������������� �������� � � ������� ��� �������� �������� ������ ���������� �� �������� ������� ��� ����������� ������������ ����� ��������������������� ���� �� Rootkit-Resistant Disks Stephen McLaughlin CSE 544 - Systems Security, SP 2010 in conjunction with Kevin Butler and Patrick McDaniel (Slides adapted from Kevin Butler’s. (The good one’s are Kevin’s.)) Systems and Internet Infrastructure Security Laboratory (SIIS) Page 1 Thursday, April 8, 2010
Trust models so far • Applications ‣ Exploits, command injection, confused deputy ‣ Kaput • Operating System ‣ IOCTL, sysfs, procfs, NETLINK, /dev/mem, Windows User- Mode Driver Framework ‣ Rootkits: User-based, kernel-based, persistent and non- persistent • Virtual Machine Monitor ??? Systems and Internet Infrastructure Security Laboratory (SIIS) Page 2 Thursday, April 8, 2010
Won’t happen Systems and Internet Infrastructure Security Laboratory (SIIS) Page 3 Thursday, April 8, 2010
What’s left? • Mediation = regulating usage of data. • All data ultimately resides in persistent storage. • The disk interface is the first line of defense for data. ‣ (And a restricted one at that.) • BUT ‣ Disks have traditionally been just bit buckets Systems and Internet Infrastructure Security Laboratory (SIIS) Page 4 Thursday, April 8, 2010
Storage Today • Disk systems are being increasingly equipped with their own memory and processing capabilities ‣ e.g., hybrid hard disks (NVRAM), FDE drives (crypto ASIC) • Narrower interface means limited interaction with the rest of the system ‣ Downside: limited context for information being non-volatile memory received from the operating system and the file system: bus ASIC disk is only exposed as a I/O SATA/ disk block device ( semantic gap SCSI/ platters firmware ATA between layers) interface Systems and Internet Infrastructure Security Laboratory (SIIS) Page 5 Thursday, April 8, 2010
Semantic Gap • MPS for storage ‣ Subjects? ‣ Objects? ‣ Operations? Systems and Internet Infrastructure Security Laboratory (SIIS) Page 6 Thursday, April 8, 2010
Semantic Gap • MPS for storage ‣ Subjects? Just one: the entire host system ‣ Objects? ‣ Operations? Systems and Internet Infrastructure Security Laboratory (SIIS) Page 7 Thursday, April 8, 2010
Semantic Gap • MPS for storage ‣ Subjects? Just one: the entire host system ‣ Objects? Blocks ‣ Operations? Systems and Internet Infrastructure Security Laboratory (SIIS) Page 8 Thursday, April 8, 2010
Semantic Gap • MPS for storage ‣ Subjects? Just one: the entire host system ‣ Objects? Blocks ‣ Operations? Read / Write Systems and Internet Infrastructure Security Laboratory (SIIS) Page 9 Thursday, April 8, 2010
Semantic Gap • MPS for storage ‣ Subjects? Just one: the entire host system ‣ Objects? Blocks ‣ Operations? Read / Write Label state, transition state, credentials??? Systems and Internet Infrastructure Security Laboratory (SIIS) Page 10 Thursday, April 8, 2010
Need to add semantics • First, we should understand what type of policies can be reasonably enforced • Disks not useful for secrecy ‣ Once a block is read, it’s gone • Disks very useful for integrity ‣ Storage is the last stop for every write • Policies stack nicely • Every modification to a piece of data is mediated • Integrity violation is required for a particular class of attack ... Systems and Internet Infrastructure Security Laboratory (SIIS) Page 11 Thursday, April 8, 2010
Rootkit Persistence • Infecting the storage makes a bad problem worse • Rootkits may try to make themselves persistent ‣ modify binaries or configuration files to insert themselves into the boot process • Q: How do you know if the rootkit has been eradicated if it becomes persistent? ‣ A: You don’t -- only surefire way of removing it is to wipe the disk clean and reinstall the OS ‣ Solving the problem of rootkits is akin to solving the general problem of malicious software ‣ However... what if we can prevent rootkit persistence? Systems and Internet Infrastructure Security Laboratory (SIIS) Page 12 Thursday, April 8, 2010
Goals for a disk solution • Protection against real rootkits ‣ demonstrable protection against currently deployed persistent kernel-level rootkits • Usable without user interaction and with minimal administration ‣ transparent operation • Highly performant ‣ minimize performance overhead • Low storage overhead ‣ as little metadata storage as possible Systems and Internet Infrastructure Security Laboratory (SIIS) Page 13 Thursday, April 8, 2010
Rootkit-Resistant Disks • Disk enforcement of block immutability prevents critical data from being overwritten by malicious agents ‣ Hence, preventing a compromised OS from infecting its on-disk image • Users directly interface with the disk using a physical token, creating a trusted path to the disk drive enclosure non-volatile memory ‣ token carries a capability that provides context bus token authorization I/O interface point to the disk SATA/ disk SCSI/ platters firmware ATA interface Systems and Internet Infrastructure Security Laboratory (SIIS) Page 14 Thursday, April 8, 2010
RRD Overview • Under normal operation where no tokens are present, the RRD is used App App as a regular disk Host File File System System • When a token is inserted, blocks Write OK Write Denied written are labeled with the token’s label and marked as immutable Disk • Once that token is removed, any writes to the labeled block are NVRAM blocked Current Token ‣ malicious software unable to write itself to immutable portions of the disk - prevents rootkit persistence Systems and Internet Infrastructure Security Laboratory (SIIS) Page 15 Thursday, April 8, 2010
Extended Filesystem Layout byte 1024 Blk grp 0 boot super- block block inode data blocks bitmap inode table block block GDT bitmap Blk grp 1 backup backup block inode data blocks bitmap inode table SB BGDT bitmap Blk grp 2 block inode data blocks bitmap inode table bitmap Blk grp 3 backup backup block inode data blocks bitmap inode table SB BGDT bitmap Blk grp 4 block inode data blocks bitmap inode table bitmap . . . Systems and Internet Infrastructure Security Laboratory (SIIS) Page 16 Thursday, April 8, 2010
RRD Setup & Operation • Initial installation of the drive best done from a trusted boot (e.g., root of trust install) • Initial disk setup is a three-step process: ‣ Write filesystem structures that need to be written by any process (e.g., journal, log, block & inode bitmaps) with permanently mutable token ‣ Write critical system data (e.g., MBR, boot loader, kernel, kernel modules), system binaries and configs with immutable token ‣ Rest of installation and subsequent operation of disk performed without a token • Tokens only necessary again when upgrading OS Systems and Internet Infrastructure Security Laboratory (SIIS) Page 17 Thursday, April 8, 2010
Upgrading • Upgrades should have their own runlevel to prevent pollution of blocks with the immutable token ‣ something akin to single-user mode ‣ Vista supports something similar: shuts down services before upgrades are applied • OS must sync buffers with the disk before entering and leaving this runlevel ‣ Same rationale, want to prevent block pollution Systems and Internet Infrastructure Security Laboratory (SIIS) Page 18 Thursday, April 8, 2010
Block Write Policy 1: for all blk in Request do ℓ b ← L ABEL O F ( blk ) 2: ℓ t ← L ABEL F ROM T OKEN () 3: if ℓ b � = nil and ℓ b � = ℓ pm and ℓ b � = ℓ t then 4: 5: return ‘Write denied’ 6: end if if ℓ b = nil and ℓ t � = nil then 7: ℓ b ← ℓ t 8: 9: end if 10: end for 11: return ‘Write OK’ Algorithm 1: RRD-write. Only if a block is unlabeled or has the Systems and Internet Infrastructure Security Laboratory (SIIS) Page 19 Thursday, April 8, 2010
Implementation • Linksys NSLU2 (“slug”) provides disk processing capabilities • netblock provides block device over network to slug (only necessary because no direct interface access to disk) • label read from token by netblockd, writes compared against BLOCK_LABELS RRD Host External Drive Slug Application netblock netblockd* client* User Space /dev/sda /mnt/nvram Kernel Space BLOCK-LABELS /mnt/token File System udev* slugos 4.8 Physical Token Linux kernel RRD Driver* Systems and Internet Infrastructure Security Laboratory (SIIS) Page 20 Thursday, April 8, 2010
Recommend
More recommend
