Kernel Memory Protection by an Insertable Hypervisor which has VM Introspection and Stealth Breakpoints (IWSEC2014)

National Institute of Advanced Industrial Science and Technology

l iKernel Memory Protection by an Insertable Hypervisorby an Insertable Hypervisor which has VM Introspection

and Stealth Breakpoints

Kuniyasu Suzaki*, Toshiki Yagi*, Kazukuni Kobara*, Toshiaki Ishiyama ‡

* N i l I i f Ad d I d i l S i d T h l (AIST)* National Institute of Advanced Industrial Science and Technology(AIST) ‡ FFRI, Inc., Japan

The 9th International Workshop on Security (IWSEC) at Hirosaki, Japan, 27/August/2014


O liOutlineM i i• Motivation

• Requirements for our countermeasure– Insertable hypervisor– VM Introspection– Stealth Breakpoints

• ImplementationImplementation • Performance evaluation of current prototype

R l t d k• Related works• Conclusion


Motivation 1/2Motivation 1/2• C rrent De ice Dri ers are• Current Device Drivers are

– Key components:D i D i b id b t l i l f ti t d• Device Drivers bridge between logical space of operating system and physical space of devices.

– Intelligent:Intelligent: • Device Drivers are stackable and can add intelligent functions. The

intelligent functions include sensitive data (e.g., secret keys for disk ti d f th ti ti t bl f t l t )encryption, passwords for authentication, tables of access control, etc).


Motivation 2/2Motivation 2/2• Are De ice Dri ers safe?• Are Device Drivers safe?

– Device Drivers were thought to be safe since they run in privilege mode However device drivers become a target ofprivilege mode. However, device drivers become a target of attacks as the importance is increased, and vulnerabilities are revealed.

– Stuxnet[5] and Duqu[3] are famous attacks for device drivers. • They are targeted attacks on nuclear reactor, chemical plant, etc.y g p

– If target device driver works on a critical infrastructure, the availability is important. The countermeasures must be taken without stopping the operating system.


Th t M d lThreat Model• 2 attack vectors2 attack vectors

– Attack on device driver’s code• Code injection attack• Code injection attack

– The aim is to take control and run malware.

• Sabotage on infrastructure systems• Sabotage on infrastructure systems– Even if the attack cannot get the full control, failure (Blue

Screen of Death of Windows) is enough because the attacker wants to stop the system.

– Attack on device driver’s sensitive data • Data Falsification

– Change the sensitive data and cause sabotage.

• Information leakage– Steal sensitive data in device drivers.


DriverGuad: hypervisor whichDriverGuad: hypervisor which protects device drivers

A C l ( hi li h)• Access Control (white list approach)– Accesses to code and sensitive data of device drivers are verified.– Legitimate accesses are allowed.

• Don’t stop the OS. It’s the attacker’s purpose!– When a malicious access is detected, the DriverGuard brings the

control to low Interrupt ReQuest Level (IRQL).

• Target is device driver on Windows 7 32bit– Code regiong

• A write access is hooked and brought to IRQL.

– Sensitive data region• All accesses are hooked. Access from legitimate code region is allowed,

but access from non- legitimate code region is brought to IRQL.


R i t f C tRequirements for Countermeasure• Insertable hypervisor to an existing OS• Insertable hypervisor to an existing OS

– Most systems use preinstalled OS (Windows), especially Industrial Control Systems (ICS) They want to add onIndustrial Control Systems (ICS). They want to add on security.

• VM IntrospectionVM Introspection– DriverGuard needs to recognize memory map and behavior

of OS.of OS.– DriverGuard protects code region using VM Introspection.

• Stealth Breakpoints• Stealth Breakpoints– DriverGuard must hooks and investigates accesses to

sensitive data but current breakpoint is not suitablesensitive data, but current breakpoint is not suitable.


Insertable HypervisorInsertable Hypervisor• Thin type-I (bare-metal) hypervisor

P th h hit t (BitVi [VEE’09])– Para-passthrough architecture (BitVisor[VEE’09])• No Device Model. Guest OS can access devices directly.

Small Trusted Computing Base (TCB)– Small Trusted Computing Base (TCB)• No HostOS make small TCB.

• DriverGuard uses Chainload function of GRUB boot loader• DriverGuard uses Chainload function of GRUB boot-loader.BIOSExisting System

GRUB D i G d

Go back to GRUBApplications(User Space)

GRUB DriverGuard(resides in memory)

chain loader

Preinstalled OS

DriverGuard(hypervisor) Insert at boot time

NTLDR Windows(Windows Bootloader)

(hypervisor)

Hardware


VM IntrospectionVM Introspection• DriverGuard must recognize the memory map and

behavior of the guest OS since it needs to know memory regions for code and sensitive data. The function is called “VM introspection”.– Ether[CCS’08] on Xen, LibVM on KVM, Xen, and QEMU.– Unfortunately, they requires Host OS and Device Model.

• DriverGuard uses GreenKiller [BlackHat’08]– GreenKiller has VM Introspection which is built on BitVisor– GreenKiller has VM Introspection which is built on BitVisor.

Unfortunately, GreenKiller is designed for Windows XP which has no ASLR (Address Space Layout Randomization).( p y )


VM Introspection for ASLRVM Introspection for ASLR• ASLR (Address Space Layout Randomization).( p y )

– It allocates the starting address of code and data at random and prevents attacks which assume fixed address (e.g., buffer overflow attack).

– Some implementations of ASLR have little entropy and are vulnerable for Brute Force Attack [CCS’04].

• DriverGuard uses the technique of brute force attack– The search space is not wide. DriverGuard checks the header

(44 bytes) of each page of kernel space.


VM Introspection of DriverGuard② System Call “IopLoadDriver”

VM Introspection of DriverGuard

Windows kernel

loads a driver

Driver A(protected)

③ Detect Sensitive Data Region① Boot parameter (MD5 of device driver)

Hooked by DriverGard

DriverGuard

A tagged region used by System call “ExAllocatePoolWithTag”

① Boot parameter (MD5 of device driver)tells a driver identification to protect

All Code Section becomes Write‐protected

A tagged rata region becomes Read/Write‐protected

Physical MemoryDriver A Code

Driver A Data

Write Protect Tagged data regionRead/Write Protect


Protection mechanismProtection mechanism• Code region• Code region

– Windows sets Read-Only protection on code region.Wh i i i d h d i i– When a write access is issued to the code region, it causes exception handler (Bug Check Code) which leads Blue Screen of Death (BSoD)Screen of Death (BSoD).

– DriverGuard hooks the exception handler and brings the control to low Interrupt ReQuest Level (IRQL).control to low Interrupt ReQuest Level (IRQL).

• Sensitive data regionWindows offers no protection mechanism on data region– Windows offers no protection mechanism on data region.

– The technique of Stealth breakpoints is used, because current breakpoint technique is not adequate for our purposebreakpoint technique is not adequate for our purpose.


W k i t t b k i tWeak points on current breakpointsB k i h i i d h k b• Breakpoint technique is used to hook accesses, but current Breakpoint is not enough for our purpose.– Software breakpoint

• It replaces a target instruction with software fault instruction (INT 3 on X86) and causes software fault.

• Unfortunately, it is not used for data because it must execute software fault.

– Hardware breakpoint• It sets an address to cause interrupt . It can be used for data.• Unfortunately, the number of hardware breakpoint is

limited because it uses debug register on X86.


Stealth breakpointsStealth breakpoints [ACSAC’05]

• Stealth Breakpoints is developed to analyze malware• Stealth Breakpoints is developed to analyze malware.– Because malware detects current breakpoints and changes its

behaviorbehavior.

• Stealth Breakpoints manipulates page table entry (PTE) and causes page fault when an access come to the breakand causes page fault, when an access come to the break point.

Pros– Pros• No limit of the number• It can treat code and data regionsIt can treat code and data regions

– Cons• The unit is page (4KB)p g ( )• Slower than software fault


Mechanism of Stealth BreakpointsMechanism of Stealth Breakpoints• P-bit (Persistent-bit) for swap out is used.

CR3 Page Table Directory

Process A (Normal)③ The page fault from legitimate code is allowed.

( ) p

0x88001000 0x411010000x88002000 0x411020000x88003000 0x41103000 Physical Memory

legitimate code is allowed.

… …… … 0x41101000

0x411020000 41103000

…① Set the P-bit (Persistent bit) to 0 by DriverGuard.② Legitimate Access

0x41103000……

0 88001000 0 41101000

CR3 Page Table Directory

Process B (Malicious)

0x88001000 0x411010000x88002000 0x411020000x88003000 0x41103000

③’ The page fault from non legitimate code is denied by DriverGuard.

… …… …

① Set the P-bit (Persistent bit) to 0 by DriverGuard.②’ Malicious Access


Behavior of DriverGuardBehavior of DriverGuardwith Stealth Breakpoints

A n access is issued.

Gate of Page Table

VMX non-root(Driver)

VMX root(DriverGuard)

① Page fault occurred. VMEnter to DriverGurad.VMEnter

Investigate the access non legitimate

② Set hardware breakpoint(The next instruction is set.)

③ Enable PTE (Set 1 on P-bit of Page Table Entry)

legitimateinfinite IRQL

(Set 1 on P bit of Page Table Entry)VMExit from DriverGurad.

The access is allowed.

The next instruction

VMEit

④ Trap hardware breakpointVMEnter to DriverGurad.

⑤ Clear hardware breakpoint⑥ Disenable PTE

The next instructioncases hardware breakpoint

VMEnter

(Set 0 on P-bit of Page Table Entry)VMExit from DriverGurad.

The next instruction is executed. VMEit


Implementation of DriverGuardImplementation of DriverGuard• Dri erG ard is based on BitVisor [VEE’09]• DriverGuard is based on BitVisor [VEE’09]• Target is Windows 7 (32 bit)

– Limitations• Page size is 4KB. Windows cannot treat PSE: Page Size Extension.

Hib i i d• Hibernation is not treated.• Device Driver is loaded with IopLoadDriver system call.• Sensitive data is allocated by tagged memory (which causes SystemSensitive data is allocated by tagged memory (which causes System

call “ExAllocatePoolWithTag”)

• Core2 Duo E6850 (3GHz)( )– DriverGuard uses 170 MB memory.

• It means that the memory for Windows 7 is reduced.


Overhead on Core2DuoOverhead on Core2Duo• The overhead was measured by DriverGuard.

– The first VMEnter and last VMExit was not measured, because the time is ,measured in the DriverGuard.

– VMEnter and VMExit spend thousands of CPU cycles on Core2 Duo.

VMEnter


VMX root(DriverGuard)

① Page fault occurred ② Set Hardware breakpoint③ Enable PTE

5 usecVMExit

Access to sensitive data

④ Trap Hardware breakpoint⑤ Clear Hardware breakpoint⑤ Disenable PTE

VMEnter

18 usec

⑤ Disenable PTE

22 usecVMExit


Overhead on Core2DuoOverhead on Core2Duo• The overhead caused by DriverGuard was 9 usec, while VMExit

and VMEnter used 13 usec.• Most part of the time was used by VMExit and VMEnter.

VMEnter


VMX root(DriverGuard) Time used by

DriverGuard

① Page fault occurred ② Set Hardware breakpoint③ Enable PTE

5 usec

5 usecVMExit

Access to sensitive data

13 usecused by VMExit and VMEnter

④ Trap Hardware breakpoint⑤ Clear Hardware breakpoint⑤ Disenable PTE

VMEnter

18 usec4 usec

VMEnter.

⑤ Disenable PTE

22 usecVMExit


OverheadOverhead• The o erhead time is hea for one access to normal• The overhead time is heavy for one access to normal

memory.h h d i bl f i i d hi h• The overhead is acceptable for sensitive data which are

used a few times, for example, authentication.• The overhead of VMEnter/VMExit is improved on current

CPU– The overhead of the prototype was measured on Core2 Duo.


Related WorksRelated Works• Hypervisor which protect devices• Hypervisor which protect devices

– SecVisor[SOSP’10]• It requires additional hyper-calls• It requires additional hyper-calls.

– HUKO[NDSS’11]• It is designed to protect the kernel from untrusted device driver.It is designed to protect the kernel from untrusted device driver.

• Taint tracking technique is useful to prevent information leakageleakage.– Some hypervisors have taint tracking

• TTAnalyze [EICAR’06] TEMU[ICISS’08] V2E[VEE’12]TTAnalyze [EICAR 06], TEMU[ICISS 08], V2E[VEE 12]

– They take much time, because they must track a target data all time.


ConclusionConclusion• We propose a thin hypervisor “DriverGurad” which p p yp

protect Device Driver’s Memory.– DriverGurd uses techniques of VM Introspection and Stealth q p

Breakpoints.– It protects code and sensitive data region of device driver.– It does not stop the guest OS in order to be used in infrastructure

systems.

A k l d tAcknowledgementThis work was in part supported by the Strategic Information and Communications R&D Promotion Programme(SCOPE) of the Ministry of Internal Affairs and Communications, Japan.