True memory isolation and kernel self-protection with KERNSEAL™

Currently in beta, this world-first security feature provides the missing pieces needed to ensure a solid foundation for any form of OS/hypervisor security and paves a path for addressing data-only attacks. Grsecurity patches featuring KERNSEAL™ protect critical data structures in the kernel and KVM hypervisor against modification, as well as hide sensitive data against disclosure. These security goals are achieved without reliance on any hypervisor or specific Intel/AMD CPU feature, ensuring any x86 server can benefit. More details will be released in an upcoming blog.

Prevents same-type object reuse exploits

Same-type object reuse is a very important vulnerability class due to its reliability and capabilities it provides an attacker. Exploits can impersonate the credentials of a fully-privileged task, or operate with full read/write access to any file opened on the system. Grsecurity addresses exploitation of this vulnerability class for file and credential structures through a probabilistic defense assisted by another of our compiler plugins.

Kernel stack isolation

The PRIVATE_KSTACKS feature isolates every process' kernel stack from all others. This provides security benefits far beyond what hardware-based shadow stacks can offer. Because accessing select data from a remote task's stack can happen under benign conditions as well, an associated compiler plugin moves such data automatically off the stack, allowing for data expected to be shared to be accessed normally, while private stack contents stay invisible to other tasks, unable to be read or corrupted. All 64-bit x86 CPUs can make use of this feature.

Compiler-based kernel heap hardening

AUTOSLAB is a fully-automated isolation-based approach to preventing kernel heap exploitation, the most common category of modern Linux kernel exploits. This novel, compiler-based defense available only in grsecurity® provides the added benefit of greatly improved kernel diagnostics by assocating any kernel heap address with specific allocation sites, down to the filename and exact line number. This production-grade defense requires no expensive run-time debugging features to be enabled.

Industry-leading ASLR

Grsecurity has led the way over the years in providing a proper ASLR implementation that deals with the many ways in which an attacker can influence ASLR or defeat it through system-provided information leaks and entropy reduction. In addition, the number of bits of entropy applied to randomization of each memory region is significantly higher in grsecurity compared to upstream's weaker ASLR implementation.

Bounds checks on kernel copies to/from userland

This feature hardens the functions the Linux kernel uses to copy data to and from user applications. It ensures copies to/from a heap object don't exceed the object's size and that stack copies don't exceed the size of the stack frame. It further prevents modifying or leaking sensitive kernel objects via these functions.

Prevents direct userland access by kernel

Through PaX's UDEREF feature, grsecurity forces any userland data access to go through an approved accessor. This prevents exploitation of an entire class of vulnerabilities that includes null pointer dereferences and dereferences of magic values that point into userland (e.g. 0xAAAAAAAA on 32-bit systems). This feature is provided for x86, x64, and ARM, even on systems without SMAP or PAN support.

Prevents userland code execution by kernel

PaX's KERNEXEC feature effectively prevents the kernel from executing code in userland through memory corruption. This feature is provided for x86, x64, and ARM, even on processors that don't support SMEP or PXN."

Prevents kernel stack overflows on x64

While vulnerabilities arising through the improper use of variable-length-arrays (VLAs) and runtime stack allocation are handled automatically with a GCC plugin, grsecurity also provides a feature to prevent exploitation arising from other sources of kernel stack overflows: deep nesting and recursion. On a mainline Linux kernel, a kernel task is free to overflow its stack into adjacent heap objects in order to escalate privilege. Grsecurity places kernel stacks non-contiguously in a separate memory region on 64-bit architectures to avoid any such abuse.

Hardened userland memory permissions

Though mainline Linux now supports NX and a weaker ASLR, by default it does nothing to prevent the introduction of malicious code into a process. While initial control flow hijacking may occur through ROP, the pattern consistently seen on Windows and other OSes is that the majority of the exploit's payload is performed within allocated RWX memory. Grsecurity eliminates this weakness by default, greatly driving up the costs of exploitation and raising the bar above the capabilities of most attackers.

Random padding between thread stacks

Linux distros generally do not compile code with the -fstack-check flag to GCC, making it possible to exploit incorrectly-sized calls to alloca(). By taking advantage of pthread's behavior of allocating quickly-created thread stacks adjacent to each other, the stack of another thread can be reliably modified to achieve exploitation. Randomizing the offset between thread stacks removes the reliability of this technique, generally reducing the exploit to a crash.

Hardened BPF JIT against spray attacks

The Linux kernel contains functionality that allows it to generate machine code at runtime to speed up packet filtering and SECCOMP rules. This functionality can be abused by attackers as they are able to both pre-determine the contents of the generated machine code and also fully control certain arbitrary values within that content that permit them to execute arbitrary code through an unintended instruction sequence. Grsecurity uses a technique called "constant blinding" to prevent an attacker from having enough control over the generated machine code to launch a successful attack. Unlike upstream's attempts at resolving this problem, our solution is resistent to leaks of the location and contents of the JIT-generated code.

In the default, JIT-disabled mode, grsecurity also protects the execution environment against a corrupted interpreter buffer.

Finally, the use of RAP will prevent JIT spray attacks in general by ensuring that no functions can call, jump, or return to anywhere in the middle of a JIT-compiled BPF filter.

Automatically responds to exploit bruteforcing

Even if all system-level infoleak sources and methods of entropy reduction are closed down, there remains the fact that a Linux system is generally unable to prevent bruteforcing of arbitrary network services and suid/sgid binaries. Grsecurity solves this issue by forcing a delay between forks of network services being bruteforced and bans users from executing suid/sgid apps for a period of time if they cause one to crash. Grsecurity takes a similar approach to preventing repeated attempts at exploiting kernel vulnerabilities. After the first detected attempt causing an OOPS message, grsecurity bans that unprivileged user from the system until restart.