Theo De Raadt plans to strengthen the W^X (Write XOR Execute) memory protection mechanism. The essence of the mechanism is that memory pages of a process cannot be simultaneously accessible for writing and execution. Thus, code can only be executed after writing is prohibited, and writing to a memory page is possible only after execution is prohibited. The W^X mechanism helps protect user-space applications from typical attacks carried out via buffer overflows, including stack overflows, and is active in OpenBSD. .
From the start of work on W^X, it was clear that it would be a long journey, as there is a significant number of applications using JIT. JIT implementations can be divided into three categories:
- Switching memory between W and X states, accepting the 'cost' of a system call. .
- Creating aliases between a pair of W and X mappings of the same memory.
- The most 'dirty' option — requiring a W|X memory model that allows simultaneous writing and execution.
Currently, there are significantly fewer programs using the third variant and more using the first and second. Nevertheless, since it was necessary to run programs with W|X JIT (primarily, Chromium and Iridum), an option to mount the filesystem as 'wxallowed' was added, which allowed using memory for both writing and execution simultaneously, if the executable ELF file is marked with the 'wxneeded' marker, while the applications themselves were additionally protected using mechanisms and to limit the list of system calls used and the parts of the filesystem accessible to the application, respectively.
To further complicate the exploitation of vulnerabilities in such applications, an addition to the mechanism has been proposed , which checks whether the system call is being made from a writable memory page. If the page is writable, the process is forcibly terminated. Thus, an attacker will not be able to use system calls and will be forced to try to find the required gadgets in the JIT implementation or even do the more challenging work of detecting system call stubs directly within .
Chrome/Iridium processes are quite reliably protected using pledge and unveil, but the restriction of using system calls like write(2) obviously has its advantages, as it creates additional difficulties for attackers. However, challenges may arise if JIT implementation uses native system calls from W|X memory. Nonetheless, there is reason to hope that this will not be encountered, as the ABI has changed multiple times, but no problems have ever been reported.
The changes are already available in the regular snapshots of the OpenBSD-CURRENT branch, and all interested parties are invited to test them.
Theo's related news about the introduction of a mode in Chrome/Iridium deserves a separate comment. . From his perspective, this is acceptable for certain use cases, but likely not for all, as it will apparently increase the load on the processor. Currently, Chrome will primarily operate if 'wxallowed' is disabled for /usr/local, although some extensions may encounter issues (for example, ghostery is mentioned). In any case, Theo hopes that full functionality in JITless mode will be brought to a completely operational state soon.
Source: opennet.ru
