Kees Cook, a former chief sysadmin at kernel.org and leader of the Ubuntu security team, now working at Google to protect Android and ChromeOS, has released a set of patches that randomize the kernel stack offsets when handling system calls. Patches improve kernel security by changing the stack location, lor that makes stack attacks much more difficult and less successful
The original idea for the patch belongs to the PaX RANDKSTACK project. In 2019, Elena Reshetova, an Intel engineer, tried to create an implementation of this idea, suitable for inclusion in the main makeup of the Linux kernel.
Subsequently, the initiative was taken by Kees Cook who presented a suitable implementation for the main version of the kernel and whose patches are planned for version 5.13 of Linux.
The mode will be disabled by default and to enable it, the kernel command line parameter is offered "Randomize_kstack_offset = on / off»And settings CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT, In addition, the overhead of enabling the mode is estimated at approximately 1% loss of performance.
The essence of the proposed protection is to choose a random stack offset on each system call, which complicates the determination of the stack layout in memory even if address information is received, since the base address of the stack will change on the next call.
Unlike the implementation of PaX RANDK STACK, in the patches proposed for inclusion in the kernel, randomization is not done at the initial stage, but after setting the pt_regs structure, which makes it impossible to use ptrace-based methods to determine a random offset during a long-duration system call.
As Linux kernel heap protections have constantly improved (vmap-based heap mapping with protection pages, thread_info removal, STACKLEAK), attackers have had to find new ways for their exploits to work.
They have, and continue to rely on kernel stack determinism, in situations where VMAP_STACK and THREAD_INFO_IN_TASK_STRUCT they were not relevant. For example, the following recent attacks would have been hampered if the stack offset was not deterministic between system calls
The purpose of the randomize_kstack_offset function is to add a random offset after pt_regs has been pushed onto the stack and before the rest of the thread stack is used during system call processing, and change it each time a process issues a system call. The source of randomness is currently defined by the architecture (but x86 uses the low byte of rdtsc ()).
Future enhancements are possible for different sources of entropy, but outside the scope of this patch. Also, to add more unpredictability, new offsets are chosen at the end of system calls (the time of which should be less easy to measure from user space than at the time of entry of the system call) and They are stored in one variable per CPU, so that the lifetime of the value does not remain explicitly tied to a single task.
There are no visible changes for this on x86 because the stack saver is already unconditionally disabled for the compilation unit, but the change is required in arm64. Unfortunately, there is no attribute that can be used to disable the stack saver for specific functions. Comparison with the PaX RANDKSTACK function: The RANDKSTACK function randomizes the location of the start of the stack (cpu_current_top_of_stack), that is, it includes the location of the pt_regs structure on the stack.
Initially, this patch followed the same approach, but during recent discussions it has been determined to be of little value as if the ptrace functionality is available to an attacker, you can use PTRACE_PEEKUSR to read / write different offsets to the pt_regs structure, observe the cache behavior of accesses pt_regs and find out the random stack offset.
Finally it is mentioned that initial implementation supports ARM64 and x86 / x86_64 processors.