A Hardware-Assisted Virtualization Based Approach on How to Protect the Kernel Space from Malicious Actions

Size: px

Start display at page:

Download "A Hardware-Assisted Virtualization Based Approach on How to Protect the Kernel Space from Malicious Actions"

Deborah Short
5 years ago
Views:

1 A Hardware-Assisted Virtualization Based Approach on How to Protect the Kernel Space from Malicious Actions Eric Lacombe 1 Ph.D Supervisors: Yves Deswarte and Vincent Nicomette 1 eric.lacombe@security-labs.org LAAS - CNRS Toulouse (France) 1 / 31

2 Context Hardware/Software complexity Security flaws Flaws exploitation Attackers achieve malicious goal Kernel = Computer System Core Provides the system services to applications Handles hardware resources Kernel security flaws Critical Widespread inside device drivers Kernel = privileged target for attackers 2 / 31

3 Issue Context and Issue Two problems that we want to work on: 1 How to prevent malware from entering the kernel? 2 How to protect the system when the kernel is compromised? 3 / 31

4 Outlines 1 Access Vectors to Corrupt the Kernel Classes 2 Preserving the Constraints on Kernel-Constrained Objects Hytux: a Lightweight Hypervisor / 31

5 Hypothesis Context and Issue Access Vectors to Corrupt the Kernel Classes Focus on attacks against kernel integrity Loss of integrity of the Kernel Inappropriate modification of: Kernel internals = Code of the kernel or Kernel environment = Data used by the kernel (e.g., data in memory, processor registers) Leads to: Nothing (injection/modification of unused data/code) or System crash or Processing of a wrong action (inappropriate wrt. the security policy) We do not consider hardware flaws 5 / 31

6 Outlines Context and Issue Access Vectors to Corrupt the Kernel Classes 1 Access Vectors to Corrupt the Kernel Classes 2 Preserving the Constraints on Kernel-Constrained Objects Hytux: a Lightweight Hypervisor / 31

7 CPU-based Access Vectors Access Vectors to Corrupt the Kernel Classes 1 category: system features Software features: Kernel module loader, /dev/kmem, etc. Hardware features: System Management Mode of x86 CPU 2 category: system flaws Buffer overflows Format strings Usage of incorrect data Usage of outdated data Etc. 7 / 31

8 DMA-Based Access Vectors Access Vectors to Corrupt the Kernel Classes DMA = Direct Memory Access without CPU involvement Malicious devices connected to a DMA-capable I/O bus (e.g., Firewire) A generic solution: DMA access filtered by I/O MMU Malicious device drivers that order wrong DMA transactions Note: Usage of one access vector may open new access vectors Example: 1 Disabling/Altering I/O MMU (CPU-based AV) 2 DMA reads/writes 8 / 31

9 Outlines Context and Issue Access Vectors to Corrupt the Kernel Classes 1 Access Vectors to Corrupt the Kernel Classes 2 Preserving the Constraints on Kernel-Constrained Objects Hytux: a Lightweight Hypervisor / 31

10 Access Vectors to Corrupt the Kernel Classes Class 1 - Invalid Modification of Kernel-Mode Execution Paths (Code) Provoke modification of kernel behaviour, by altering kernel-mode code: (Class 1.1) Addition of a reachable malicious kernel code region (Class 1.2) Overwriting an existing kernel code region with malicious code (Class 1.3) Injection of reachable malicious code into a kernel data region (Class 1.4) Injection of reachable malicious code into a non-kernel region 10 / 31

11 Access Vectors to Corrupt the Kernel Classes Class 2 - Invalid Modification of Kernel-Mode Variables Provoke modification of kernel behaviour, by altering data it uses: (Class 2.1) Alteration of state variables (impact execution flow): The control flow data in the stack Data used in a branching condition Attributes of page tables Value of the idtr register etc. (Class 2.2) Alteration of auxiliary variables: Description of an error displayed by printk() / 31

12 Outlines Context and Issue Preserving the Constraints on Kernel-Constrained Objects Hytux: a Lightweight Hypervisor 1 Access Vectors to Corrupt the Kernel Classes 2 Preserving the Constraints on Kernel-Constrained Objects Hytux: a Lightweight Hypervisor / 31

13 A Kernel Full of Constraints Preserving the Constraints on Kernel-Constrained Objects Hytux: a Lightweight Hypervisor Kernel-Constrained Objects (KCO) Kernel variables Always in a fixed or predictable state by specification No matter implementation bugs or design flaws For instance: IDT (Interrupt Descriptor Table) and the idtr register are KCO Kernel Address Space Layout is composed of several KCO 13 / 31

14 Preserving the Constraints on Kernel-Constrained Objects Hytux: a Lightweight Hypervisor How to Protect Kernel-Constrained Objects Need to be done at a higher hardware privilege level than the kernel Practicable thanks to hardware virtualization technology Not a full hypervisor, but a really lightweight one Easier verification of its correctness Our approach: Unique ability to restrict the kernel mode Overcome numerous malicious actions by preventing constraint violations 14 / 31

15 Outlines Context and Issue Preserving the Constraints on Kernel-Constrained Objects Hytux: a Lightweight Hypervisor 1 Access Vectors to Corrupt the Kernel Classes 2 Preserving the Constraints on Kernel-Constrained Objects Hytux: a Lightweight Hypervisor / 31

16 Hytux Overview Preserving the Constraints on Kernel-Constrained Objects Hytux: a Lightweight Hypervisor 16 / 31

17 Intel VT-x Quick Overview Preserving the Constraints on Kernel-Constrained Objects Hytux: a Lightweight Hypervisor 17 / 31

18 Outlines Context and Issue 1 Access Vectors to Corrupt the Kernel Classes 2 Preserving the Constraints on Kernel-Constrained Objects Hytux: a Lightweight Hypervisor / 31

19 Preventing idtr from Being Modified idtr = Processor register, contains IDT address Needs to be filled only at system initialisation But may be modified by kernel malware in order to operate Hytux protects against idtr modification: Intercepts write access (thanks to VM-exit controls) Emulates this access Do not modify idtr, only updates guest program counter. Other registers similarly protected: gdtr, cr0 and cr4, MSR, etc. 19 / 31

20 Outlines Context and Issue 1 Access Vectors to Corrupt the Kernel Classes 2 Preserving the Constraints on Kernel-Constrained Objects Hytux: a Lightweight Hypervisor / 31

21 Preserving the Kernel Address Space Layout The Idea Enforce constraints on the kernel address space layout Protect the system against at least Class 1.2 and Class 1.3 Code region: NX=0, R/W=0 Data region: NX=1, R/W=1 Read-only data region: NX=1, R/W=0 21 / 31

22 Recall the Paging Mechanism / 31

23 ... and the Bare Linux Kernel Address Space Layout 23 / 31

24 A First (Wrong) Solution 24 / 31

25 A First (Wrong) Solution (Contd.) Why is it wrong? Kernel page tables needs to be modified during system execution Dynamic load of device drivers (VMALLOC area) Needs to stay in a R/W memory region But the attacker could then modify page table attributes and mess up constraints 25 / 31

26 A Good Solution Concept Set to 0 the R/W attribute of pages that contain kernel page tables When the kernel wants to modify kernel pages tables: 1 A page-fault is about to occur 2 A VM-exit is thus triggered 3 Hytux takes over the execution 4 It verifies wanted modifications do not change constraints (from the layout it knows resilient) When the kernel wants to load cr3 register (page table reference): 1 A VM-exit is triggered 2 Hytux verifies correctness of page tables last entries (kernel space) 26 / 31

27 A Good Solution (Contd.) 27 / 31

28 A Good Solution (Contd.) Notes The kernel layout may be modified in the VMALLOC area (driver/module insertion) vmalloc()/vfree() needs to inform Hytux on this changing Hytux can modify kernel page tables Acts in a context with full access to the memory 28 / 31

29 Contributions Proposition of a classification of malicious kernel-targeted actions New concept for kernel security measures: protection of Kernel-Constrained Objects Can be applied to all classes except Class 1.1 Kernel address space layout protection Overcome at least Class 1.2 and Class 1.3 First use of hardware virtualization technology to protect the host: Unique ability to restrict the kernel mode Results in the protection of the kernel against many kind of malware 29 / 31

30 Limits All system objects are not easily captured as KCO Constraints do not exist, be too loose or unobservable Malicious actions can benefit from these objects Are malicious actions still possible in an ideal world full of KCO? 30 / 31

31 Wake Up Your Neighbours......but don t let them ask questions ;) 31 / 31

Operating System Security

Operating System Security Operating Systems Defined Hardware: I/o...Memory.CPU Operating Systems: Windows or Android, etc Applications run on operating system Operating Systems Makes it easier to use resources.