Rootkit-Resistant Disks Stephen McLaughlin CSE 544 - Systems - - PowerPoint PPT Presentation

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

• Rootkit-Resistant Disks

Stephen McLaughlin CSE 544 - Systems Security, SP 2010

1

in conjunction with Kevin Butler and Patrick McDaniel (Slides adapted from Kevin Butler’s. (The good one’s are Kevin’s.))

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

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 ???

2

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Won’t happen

3

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

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

4

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Storage Today

• Disk systems are being increasingly equipped with their
• wn 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 received from the operating system and the file system: disk is only exposed as a block device (semantic gap between layers)

5

non-volatile memory disk platters firmware bus I/O SATA/ SCSI/ ATA interface ASIC

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Semantic Gap

• MPS for storage
• Subjects?
• Objects?
• Operations?

6

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Semantic Gap

• MPS for storage
• Subjects?

Just one: the entire host system

• Objects?
• Operations?

7

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Semantic Gap

• MPS for storage
• Subjects?

Just one: the entire host system

• Objects?

Blocks

• Operations?

8

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Semantic Gap

• MPS for storage
• Subjects?

Just one: the entire host system

• Objects?

Blocks

• Operations?

Read / Write

9

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Semantic Gap

• MPS for storage
• Subjects?

Just one: the entire host system

• Objects?

Blocks

• Operations?

Read / Write

10

Label state, transition state, credentials???

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

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 ...

11

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

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?

12

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

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

13

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

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

• token carries a capability

that provides context to the disk

14

drive enclosure non-volatile memory disk platters firmware bus I/O SATA/ SCSI/ ATA interface token interface authorization point

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

RRD Overview

• Under normal operation where no

tokens are present, the RRD is used as a regular disk

• When a token is inserted, blocks

written are labeled with the token’s label and marked as immutable

• Once that token is removed, any

writes to the labeled block are blocked

• malicious software unable to write

itself to immutable portions of the disk - prevents rootkit persistence

15

Disk NVRAM Current Token App File System App File System Host Write OK Write Denied

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Extended Filesystem Layout

16

boot block super- block block GDT

block bitmap inode bitmap inode table

data blocks

backup

SB

backup

BGDT block bitmap inode bitmap inode table

data blocks

block bitmap inode bitmap inode table

data blocks

backup

SB

backup

BGDT block bitmap inode bitmap inode table

data blocks

block bitmap inode bitmap inode table

data blocks

byte 1024

Blk grp 0 Blk grp 1 Blk grp 2 Blk grp 3 Blk grp 4

. . .

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

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

17

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

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

18

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Block Write Policy

19

1: for all blk in Request do 2: ℓb ←LABELOF(blk) 3: ℓt ←LABELFROMTOKEN() 4: if ℓb = nil and ℓb = ℓpm and ℓb = ℓt then 5: return ‘Write denied’ 6: end if 7: if ℓb = nil and ℓt = nil then 8: ℓb ← ℓt 9: end if 10: end for 11: return ‘Write OK’ Algorithm 1: RRD-write. Only if a block is unlabeled or has the

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

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

20

User Space Kernel Space Application File System RRD Driver* netblockd* Slug udev* /dev/sda /mnt/nvram /mnt/token slugos 4.8 Linux kernel

RRD Host

netblock client* External Drive BLOCK-LABELS Physical Token

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

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

20

User Space Kernel Space Application File System RRD Driver* netblockd* Slug udev* /dev/sda /mnt/nvram /mnt/token slugos 4.8 Linux kernel

RRD Host

netblock client* External Drive BLOCK-LABELS Physical Token

netblockd* Slug udev* /dev/sda /mnt/nvram /mnt/token slugos 4.8 Linux kernel

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

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

20

User Space Kernel Space Application File System RRD Driver* netblockd* Slug udev* /dev/sda /mnt/nvram /mnt/token slugos 4.8 Linux kernel

RRD Host

netblock client* External Drive BLOCK-LABELS Physical Token

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

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

20

User Space Kernel Space Application File System RRD Driver* netblockd* Slug udev* /dev/sda /mnt/nvram /mnt/token slugos 4.8 Linux kernel

RRD Host

netblock client* External Drive BLOCK-LABELS Physical Token

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

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

20

User Space Kernel Space Application File System RRD Driver* netblockd* Slug udev* /dev/sda /mnt/nvram /mnt/token slugos 4.8 Linux kernel

RRD Host

netblock client* External Drive BLOCK-LABELS Physical Token

block request

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

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

20

User Space Kernel Space Application File System RRD Driver* netblockd* Slug udev* /dev/sda /mnt/nvram /mnt/token slugos 4.8 Linux kernel

RRD Host

netblock client* External Drive BLOCK-LABELS Physical Token

enforcement point

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

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

20

User Space Kernel Space Application File System RRD Driver* netblockd* Slug udev* /dev/sda /mnt/nvram /mnt/token slugos 4.8 Linux kernel

RRD Host

netblock client* External Drive BLOCK-LABELS Physical Token

enforcement point

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

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

20

User Space Kernel Space Application File System RRD Driver* netblockd* Slug udev* /dev/sda /mnt/nvram /mnt/token slugos 4.8 Linux kernel

RRD Host

netblock client* External Drive BLOCK-LABELS Physical Token

enforcement point

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Evaluation

• Setup: prototype RRD (slug: 266 MHz ARM IXP420

processor, 32 MB RAM), host running Ubuntu Linux 2.6.22 kernel

• Questions we consider:
• Defenses against real

rootkits

• Performance overhead

from block labeling

• Scalability due to label

constraints

21

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Rootkit Defense

• Ran live version of Mood-NT

against the RRD

• Rootkit failed to replace

/sbin/init with its own initialization program, rebooted to normal state

• Examined chkrootkit scanner to

validate

• found over 150 files that would be

modified by 44 rootkits

• all marked immutable by RRD such

that they cannot gain persistence

• Proper labeling of files on

installation is critical

22

Adore: /usr/[lib|bin]/[start|stop].sh /usr/[lib|bin]/adore /usr/bin/atm Ramen: /etc/inetd.confab Maniac RK: /usr/bin/mailrc t0rn: /sbin/src/.puta /sbin/xlogin /lib/ldlib.tk /usr/info/t0rn /usr/local/lib/libproc.a Lion: /bin/in.telnetd /bin/mjy RK17: /usr/bin/squit /usr/bin/pback rsha: /usr/bin/n3tstat /usr/bin/kr4p /usr/bin/chsh2 /etc/rc.d/rsha ShitC: /usr/[bin|sbin]/[frgy|home|sy] /usr/bin/in.slogind Showtee: /usr/lib/liblog.o /usr/include/cron.h /usr/include/syslogs.h Romanian: /usr/include/file.h /usr/bininclude/addr.h HKRK: /etc/rc.d/init.d/network ESRK: /usr/lib/tcl5.3

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Filesystem Hierarchy Standard

• Understanding file mutability can be informed through

application of the UNIX filesystem hierarchy standard (FHS)

• enables software and users to predict the location of installed files and

directories

23

/

bin boot etc home lib sbin tmp usr var

essential command binaries static boot loader files host system configuration user directories shared libs & kernel modules system binaries temp files shareable read-only data spool files, logs, etc.

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Filesystem Hierarchy Standard

• Understanding file mutability can be informed through

application of the UNIX filesystem hierarchy standard (FHS)

• enables software and users to predict the location of installed files and

directories

23

/

bin boot etc home lib sbin tmp usr var

essential command binaries static boot loader files host system configuration user directories shared libs & kernel modules system binaries temp files shareable read-only data spool files, logs, etc.

bin lib local

share

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Filesystem Hierarchy Standard

• Understanding file mutability can be informed through

application of the UNIX filesystem hierarchy standard (FHS)

• enables software and users to predict the location of installed files and

directories

23

/

bin boot etc home lib sbin tmp usr var

essential command binaries static boot loader files host system configuration user directories shared libs & kernel modules system binaries temp files shareable read-only data spool files, logs, etc.

bin lib local

share

bin etc man

sbin

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Filesystem Hierarchy Standard

• Understanding file mutability can be informed through

application of the UNIX filesystem hierarchy standard (FHS)

• enables software and users to predict the location of installed files and

directories

23

/

bin boot etc home lib sbin tmp usr var

essential command binaries static boot loader files host system configuration user directories shared libs & kernel modules system binaries temp files shareable read-only data spool files, logs, etc.

bin lib local

share

bin etc man

sbin share

etc man

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Evaluation

24

System Install microbenchmarks:

Component

Total Time

% of measured

disk 340.5 53.8% network 288.1 44.7% security 16.4 2.5%

Postmark transactions per second:

Config.

TPS

% decrease

no security 235.1 security 231.7 1.4%

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Scalability

25

• Block label ranges take only a small amount of metadata

storage

100 101 102 103 104 105 106 mkfs copy base upgrade 1 upgrade 2 Number of Blocks or Ranges Ranges (ext2) Ranges (ext3) Blocks Labelled (ext2) Blocks Labelled (ext3)

• less than 40 KB of

storage for a 4 GB system on disk

• average label range

size: 12 bytes

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Label Creep

• If a block is labeled immutable, the label cannot be

changed (unless label is revoked): creates issue of label creep

• semantic gap between FS, storage prevents free

space reclamation

• Evaluation: after installation and 2 system upgrades,

about 10% of labeled data blocks subject to label creep (about 1% of entire partition)

• ext3 journal labeled permanently mutable, single constant

increase in labeled block size (32,768 blocks)

26

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Once Upon atime

• Consider the structure of an inode

27

mode UID size atime ctime mtime dtime GID link cnt blck cnt flags OS pointers to blocks ... file ver file ACL dir ACL frag OS ...

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Once Upon atime

• Consider the structure of an inode

27

mode UID size atime ctime mtime dtime GID link cnt blck cnt flags OS pointers to blocks ... file ver file ACL dir ACL frag OS ...

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Useful FS Modifications

• Having the filesystem fail silently is suboptimal
• Recommended: an ACCESS DENIED message

delivered to the filesystem such that writes don’t return BAD BLOCK messages and choose more appropriate inodes to write to

• We are investigating these modifications to ext3
• note that the system works without them, but it’s extra

sugar for the user and the OS

28

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Disk Maintenance Tasks

• Token duplication
• 2 available slots on disk, insert token to duplicate and

blank token

• Backup
• duplicate backup token, retrieve another RRD and put

backup token in that drive, connect together

• geometry does not need to be identical since block copy
• Revocation
• unlabel token placed in RRD with token to be revoked
• block labels associated with revoked token will be erased

from RRD

29

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Working with Windows

• RRDs are conceptually independent of the overlying
• perating system and filesystem structures
• RRD solution would work in Windows with the

following considerations taken into account:

• dealing with immutable file layout requires changes to

installer (\Windows and \Windows\System should be immutable in Windows)

• immutable portions of the Windows registry (make

certain hives immutable)

• Registry virtualization in Vista: remap read-only registry

settings to user home directories (limits the effects of system registry settings going awry) = no writes needed

30

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Effects of Ext4

• Extents: are beneficial to us
• By setting larger ranges on where a file may write, longer

series of contiguous blocks are allocated, meaning less metadata needs to be stored on the disk

• Multiblock allocation: similar benefits
• Allocate-on-flush (Delayed Allocation)
• Blocks allocated for pending writes are not allocated until

flushed by OS

• Allows more contiguous writes but doubly important that

sync must be called before immutable token released

31

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Lessons

• Enforcing block immutability at the disk can prevent

malicious writes to critical operating system files, providing resistance against persistent rootkits

• Reference monitor guarantees at the disk level have

wide implications for policy

• Future direction: RRD is a specific case of a more

general problem

• what if we consider the binding of entire operating

systems to a series of tokens and enforce a policy over that?

• what about allowing greater interaction with the host?

32

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Future work:Token Usability

• Little work has been done in the area of token

usability in a security context

• Piazzalunga et al. wrote one of the few studies explore

security of tokens from user standpoint

• Our goal: Determine user experience with using

token plugged into disk for administrative tasks

• regular operation first (e.g., email, web browsing)
• tasks requiring administrator (e.g., software update)
• How do interfaces in software and hardware affect

user behavior and ability to make correct security decisions?

33

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Current Initiatives

• Investigating how to add the host to the TCB by

validating it prior to allowing the disk to divulge data

• Using commodity trusted hardware on the host

(e.g., TPM), receive attestations to integrity state

• Implemented prototype for portable storage, which

tends to be used across a variety of hosts

• Formalized a notion of continuous attestations using

LS2 logic of secure systems to prove secrecy and integrity properties

34

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Questions

35

Kevin Butler butler@cse.psu.edu

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Extra Slides

36

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Broader Case

• Device for enforcing MAC policy at the storage

layer with a trusted path from the user directly to the disk

37

Thursday, April 8, 2010

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

Related Work

• NASD (Gibson et al., ASPLOS 1998)
• Active Disks (Riedel 1999)
• Storage-based Intrusion Detection (Pennington et

al., USENIX Security 2003)

• Secure Versioning Disks (Sundararaman et al.,

USENIX Security 2008)

38

Thursday, April 8, 2010