Chaoting Xuan, John Copeland, Raheem Beyah Georgia Institute of Technology 7/9/2009 Presented by John McHugh

Kernel Rootkits
a program runs in kernel space to take fundamental control of a computer system, without authorization by the systems owners and legitimate. Joanna Rustkowska classified three types of kernel rootkits. 1) Type I: modifying static kernel objects. 2)Type II: modifying dynamic kernel objects. 3)Type III: VMM, SMM and other hardware-based rootkits.

How are malicious code inserted to the kernel ?

Loadable kernel module (LKM) or driver (most of

Linux and Windows rootkits are implemented in this way). /dev/mem, /dev/kmem and \Device\PhysicalMemory (But modifying kernel memory through them has been disabled in recent Linux and Windows versions). Exploiting the vulnerabilities of benign kernel code (like buffer overflows).

Rootkit Detection
Signature-based rootkit detection and kernel integrity

verification are two generic rootkit detection approaches, and many research works have been focused the second one. Kernel integrity verification has following limitations: 1) It is infeasible to verify all the states of dynamic kernel objects. 2)It cannot cope with non-integrity-violation rootkits, e.g., some type III rootkits and confidentialityviolation rootkits.

A Confidentiality-violation Rootkit.

Rootkit Prevention
Only authenticated/authorized LKMs/drivers are

allowed to be loaded and executed in the kernel (Microsofts driver code signing, NICKLE and SecVisor). However, no authentication/authorization authority can assure the goodness of a driver/LKM. VeriSign just sells the certificate to customers and doesnt check the driver code to be signed at all. This approach also cannot handle a large number of legacy drivers/LKMs, Windows XP and 32-bit Vista doesnt enforce the code driver signing in default.

DARK
DARK aims to assure the goodness of a LKM/driver

that computer users dont trust, while it is useful to them. It combines the program monitoring with the rootkit identification techniques. The suspicious kernel code is monitored and its interactions with the rest of kernel are checked against a group of well-selected security policies. DARK is built based on Qemu/Kqemu and its program monitoring is achieved through on-demand emulation.

On-demand Emulation

Design
Use one feature of OSs virtual memory management subsystem. Set present bits in page table entries of the LKMs

code to 0. Page fault exception is generated when the VM attempts to run the LKM code. The VMM intercepts and interprets the exception and switches to emulation mode. The emulator sets those present bits to 1 and runs the LKM code along with DARKs security policy checking.

Implementation
Reuse the existing demand emulation framework of Qemu/Kqemu. Instrument Linux kernels sys_init_module and sys_delete_module functions in kernel/module.c , and the VM issues the 0x90 and 0x91 software interrupt to VMM. Add DARKs business logics to V-2-E and E-2-V control code of Qemu/Kqemu. Modify Linux module loader (insmod.c) to store a modules text range in its module descriptor.

Security Policy
They are manually created based on expert knowledge. The basic rule format is as below:

Subject
Module X

Operation Object
Read, Write, Call Hardware Objects, Kernel Objects

Action
Alarm, Reject

ID

NAME
Console TTY Buffer
Exception Table GDT table IDT table Kernel Text MM List Module List Module Text Netfilter Hooks Page Table Proc Dir Entry List Proc Inode Ops List Proc File Ops List PTM TTY Buffer PTS TTY Buffer Socket Buffer List Syscall Table Task List Segment

OPERATION

GLOBAL VARIABLE OR FUNCTION

console_table __start___ex_table gdt_table idt_table _text init_task module_list module_list nf_register_hook init_task proc_root

DATA TYPE

ACTION

DYNAMIC

OPTIONAL

1 2 3 4 5 6 7 8 9 10 11

Read Write Write Write Write Write Write Write Call Write Write

tty_struct Exception_table_entry Array Array mm_struct Module proc_dir_entry

Alarm Alarm Reject Reject Reject Alarm Alarm Reject Alarm Reject Alarm

No No No No No Yes Yes Yes No Yes Yes

No No No No No No No No Yes No No

12
13 14 15 16 17 18 19

Write
Write Read Read Read Write Write Write

proc_root
proc_root ptm_table pts_table skbuff_head_cache sys_call_table init_task init_tss

Proc_inode_operation
Proc_file_operation tty_struct tty_struct sk_buff Array task_struct Array

Alarm
Alarm Alarm Alarm Alarm Reject Alarm Reject

Yes
Yes Yes Yes Yes No Yes No

No
No No No Yes No No No

DARK System Rules

Policy Enforcement
Kernel rules are organized as two hash tables. The LKM code is monitored at the code translation of

Qemu, and the cached code is not inspected again, which significantly improves the performance. External kernel memory accesses and function invocations can optionally be logged to a local file.

Security Evaluation
Total 18 Linux rootkits are available for the evaluation:

17 are collected from the Internet; one is written by myself. We cant find any type III rootkit that works in the testing system. 20 benign modules are selected from Linux source for false positive evaluation. All rootkits have been detected and blocked by DARK; only 1 benign module causes an alarm.

FUNCTION

HIT KERNEL RULE

ROOTKIT

HID X X X

PE X X X

REE

REC

NEU

TYPE I

Load 17 7, 12, 13 7*, 12, 13

Operation 18 18 18 15

ACTI ON Reject Alarm Alarm Alarm Reject Reject

Adore Adore-ng Adore-ng (hidden) Darklogger Exception Fileh-lkm Hookstub Hp KIS Knark Linspy2 Nfsniffer Nushu Pizzaicmp Prrf Sebek Srootkit Vlogger Vlogger (local)

X X X

II II II

X X X X X X X X X X X X

I I I II I I I II

2 17 4 18 17 17 16 9

18

18

Reject Alarm Reject

18

Reject Reject

16 16

Alarm Alarm Alarm Alarm Reject Reject

X X X X X X X X

II II II I I I II 9 11, 12, 13 7, 17 5 17

16 18

14 1

Reject Alarm

Performance Evaluation
Target LKM is iptable_filter. Three systems: VMM-only, DARK and

DARK-CS. Three benchmarks: bonnie, iperf, lmbench. When iptable_filter is excuted, DARK has about 10% performance penalty.

Bonnie Test Result

Sequential Output Per Char Block Rewrite Sequential Input Per Char Block Random Seeks

K/sec

%CPU

K/sec

%CPU

K/sec

%CPU

K/sec

%CP K/sec U

%CPU

/sec

%CP U

VMM

8528 233

643

127551 425

455

190821 490

53.03

158052 301

754

1292 92

712

35151 908

844

DARK -CS

8038 345

615

11715 1 379

416

174021 834

48.22

168602 004

805

1302 66

744

49691 759

852

DARK

8168 405

67 6

139491 106

435

187422 046

49.82

144802 720

737

1254 93

724

51171 254

834

Iperf Test Result

VM as Server (M/sec) VM as Client (M/sec)

TCP

UDP

TCP

UDP

VMM-only

21.81.2

1.050.1

26.82.3

1.130

DARK-CS

19.730.5

1.010

23.991.4

1.080.1

DARK

19.600.6

1.000.1

24.051.0

1.080.1

Future Work
Continually refine the policy rules to accommodate

new rootkit attacks. Tweak the tradeoff between performance and security: selectively enabling or disabling on-demand emulation based on certain conditions, e.g., current system load, virtual CPU usage and bandwidth usage. Port DARK to Kernel-based Virtual Machine (KVM) that supports hardware virtualization extensions such as Intels VT-x and AMDs AMD-V.