Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this pageto join up and keep LWN on the net.
ByJake Edge
December (*********************************************, *****************************************
A new mechanism to help thwartreturn-oriented programming(ROP) and similar attacks has recently been added to the OpenBSD kernel. It will block system calls that are not made via the C library (libc) system-call wrappers. Instead of being able to string together some “gadgets” that make a system call directly, an attacker would need to be able to call the wrapper, which is normally at a randomized location.
Theo de Raadtintroducedthe feature in a late November posting to the OpenBSD tech mailing list. The idea is to restrict where system calls can come from to the parts of a process’s address space where they are expected to come from. OpenBSD already disallows system calls (and any other code) executing from writable pages with itsW ^ Ximplementation. Since OpenBSD is largely in control of its user-space applications, it can enforce restrictions that would be difficult to enact in a more loosely coupled system like Linux, however. Even so, the restrictions that have been implemented at this point are less strict than what De Raadt would like to see.
The eventual goal would be to disallow system calls from anywhere but the region mapped for libc, but the Go language port for OpenBSD currently makes system calls directly. That means the main program text segment needs to be in the list of memory regions where system calls are allowed to come from. Static binaries will also need to have their text segment included, since libc will inhabit part of that address space. In his message, he described the full list of allowed memory regions:
For static binaries, the valid regions are the base program’s text segment and the signal trampoline page.
For dynamic binaries, valid regions are ld.so’s text segment, the signal trampoline, and libc.so’s text segment … AND the main program’s text.
Switching Go to use the libc wrappers (as is already done on Solaris and macOS) is something that De Raadt would like to see. It may allow dropping the main program text segment from the list of valid regions In the future:
If go is adapted to call library-based system call stubs on OpenBSD as well, this problem will go away. There may be other environments creating raw system calls. I guess we’ll need to find them as time goes by, and hope in time we can repair those also.
The kernel can mark most of the regions valid as it starts up a process, but it will not know what address space holdslibc.sofor a dynamic binary. Marking that region as valid is left to theld.sodynamic linker. It has been changed to execute a new system call,msyscall (), to mark the region occupied bylibc.soas one that is valid for making system calls.msyscall ()can only be called once by a process, so changes or additions to the valid regions are not possible onceld.sohas done so. Any process that makes a system call from a non-approved region will be killed.
Another OpenBSD security measure plays a role here as well. On boot, libc is re-linked in a random order, so that the locations of the system-call wrappers within libc are different for every running system. This change forces attackers to use those wrappers, which will be difficult to find reliably for a non-local attack.
Things move quickly in the OpenBSD world (as we saw with thekernel address-space randomized link(KARL) feature in 806776, so it was no surprise that the code for this new feature wascommitted to the OpenBSD treejust two days after it was first posted. It is an ABI break for the operating system, but that is no big deal for OpenBSD. De Raadtsaid: “ We are here at OpenBSD are the kings of ABI-instability. Hesuggestedthat relying on the OpenBSD ABI is fraught with peril:
Program to the API rather than the ABI. When we see benefits, we change the ABI more often than the API.
I have altered the ABI. Pray I do not alter it further.
This is an incremental security improvement; it is a hardening measure that It makes more difficult for attackers to reliably exploit a weakness that they find. There was no real dissent seen in the thread, so it would seem to be a relatively non-controversial change. But, once Go is changed and the main program text is not allowed to make system calls, that might change if there are other applications that need the raw system-call capability. For Linux, though, that kind of ABI change would never get very far.
************************
(
Log into post comments) **************************Read More****************
GIPHY App Key not set. Please check settings