Kernel Code Protection Mechanisms

In this section, we take a closer look at the code protection mecha-nisms that are offered by the x86 architecture and/or are leveraged by modern OS kernels.

2.1.2.1. W⊕X

As mentioned in the previous section, the x86 architecture provides an execute-disable bit as well as a read/write bit. These features can be leveraged to implementW⊕X. The general idea is that each page in the page tables is marked either as writableor as executable, but never as both. As a result, code pages cannot be simply modified by an attacker, because they are marked as executable and are therefore not writable. Similarly, data regions cannot be executed as they are writable and therefore not executable. Note that the code segment of the Linux kernel is not writable per default. To patch its code the kernel temporarily sets the code to being writable and executable effectively violating the W⊕X policy.

2.1.2.2. Trusted Boot & Module Signing

The goal of trusted boot is to ensure that each component in the boot chain is untainted and has not been modified by an attacker at load time. To provide this functionality a signature exists for each component that includes a hash value of the component. During the boot process each component verifies the next component in the boot chain by checking the validity of its signature, recomputing the hash of the component, and comparing the so obtained hash value

Background

2.1. Hardware and Operating System Background

with the hash value within the signature. If both the certificate as well as the hash value can be verified, the component is considered to be untainted and is loaded. Otherwise the boot process is aborted.

The TPM specification [96] extends this concept so that applications can later seal their keying material depending on an untainted boot process.

While a kernel module must not necessarily be loaded as part of the boot process, the trusted boot approach can be extended to include loadable kernel modules. In this case the kernel is configured to only load modules that are signed and untainted. To allow this scheme to work each module must provide its own signature that can be verified by the kernel before it is loaded. The verification process is thereby identical to the previously mentioned process.

If trusted boot is used, an attacker can no longer simply modify the kernel binary on disk as this would change the hash value of the kernel binary and it would therefore not pass the verification process on the next boot. Similarly, if module signing is used, an attacker can no longer load arbitrary modules into kernel space as the modules are verified before they are loaded. By combining trusted boot and module signing, it is thus possible to tightly restrict the code that can be loaded into the kernel space. Notice, however, that this protection mechanism does not protect the kernel fromruntime modifications.

2.1.2.3. Supervisor Mode Execution Protection (SMEP)

A common exploitation technique that is often used to execute attacker controlled code with kernel privileges is to place the desired instructions into userspace and then divert the control flow of the kernel to the userspace code region. Since the processor already executes at the highest privilege level when the control flow is diverted, it will execute the userspace instructions with supervisor privileges.

The advantage of this approach is that the attacker neither needs to alter kernel code nor does she have to load a kernel module.

Consequently, the attacker does not have to circumvent protections

2. Background

such as W⊕X or trusted boot. Instead the attacker only needs to store her instructions in userspace, which only requires control of a userspace process on the system.

To protect against such attacks, Intel introduced SMEP. With SMEP enabled, loading an instruction from a userspace page (a page that is not marked as a supervisor page in the page tables) while operating at the highest privilege level will lead to a page-fault exception [46]. Therefore the attacker can no longer divert the control flow of the kernel to userspace code as all userspace pages are marked as user pages and not as supervisor pages.

2.1.2.4. Supervisor Mode Access Prevention (SMAP)

SMAP is a similar method as SMEP for data accesses. In the case of SMAP the system can be configured to cause a trap (page fault), if the system is in supervisor mode and tries to access data that is mapped as user memory. This way an attacker needs to find a way to transfer all code and data that she needs for her exploit to the kernel before she is able to use that data in her exploit.

2.1.2.5. Memory Protection Keys for Userspace (PKU)

Intel also recently introduced a new page protection mechanism into its architecture called protection keys. In addition to the classical user-and supervisor classification, a page table entry now also contains a protection key associated with it. This key allows to classify a userspace page into 16 different protection classes for which the access rights (read and write accesses) may be set differently in each execution thread. The allowed access modes for each class are specified by corresponding bits in the userspace accessible PKRU register.

2.1.2.6. Address Space Layout Randomization (ASLR)

When ASLR is enabled, code regions such as the kernel code region are no longer loaded to a fixed address. Instead the loader generates

Background