OpenBSD system-call-origin verification

by swills • 7 years ago

112 92 7 years ago

Animats3• 7 years ago

This effectively treats libc as a trusted interface. Checking should be at the protection boundary, the system call. This just makes attacks more complicated, not less successful.

miohtama• 7 years ago

In a long run the non-complicated solution is to get rid of anything that can compile to something with a buffer overflow.

Just half trolling.

jacquesm4• 7 years ago

There goes Rust I guess...

alexgartrell• 7 years ago

If you can change libc then you have equal to or greater permissions than the calling process. So this strengthens the security model.

jacquesm4• 7 years ago

Does that mean that linking against libc is mandatory and that applications are not allowed to bring their own version of libc along for instance when linked statically?

quietbritishjim• 7 years ago

But surely applications can make syscalls directly without invoking libc at all, by setting up the registers directly and directly executing the processor instruction that causes the right software interrupt? In which case the parent comment's point still stands: you can bypass checking that's at the libc level in a way you can't bypass checking within the kernel.

vlovich1232• 7 years ago

Yes it’s more complicated but that’s how all security works and why security exploits are more expensive today than before. The reason this defense requires libc is because syscalls are not a function calls (you push args onto the stack and then trigger a software interrupt).

This defense technique is both simple (in terms of relative change from how things work today) and effective in that buffer overflows can’t ever call into the kernel but now instead have to go through libc which has had its location randomized on the application launch.

To provide this protection at the syscall layer would require some kind of randomization of how a syscall is performed which is something that has no prior art since that’s just pushing arguments into the stack and triggering an interrupt through a single instruction meaning complexity of the work is unknown in terms of how to secure a buffer overflow from being able to do that (ie harden an arbitrary process to not be able to directly jump into a syscall). Additionally because there’s no prior art the scope of that kind of change wouldn’t have the benefit of having well-understood behavior. Not impossible or prohibitive but raises the bar for the benefit you’d have to provide (& probably get a chip manufacturer and compiler vendors to go along with you). Also even if you could 3rd party binaries wouldn’t gain that protection magically. Putting this in libc is fantastic. Arguably Linux’s decision to treat libc as an external unrelated project and keep ABI comparability at the syscall layer prevents a protection mechanism like this.

Animats3• 7 years ago

Yes it’s more complicated but that’s how all security works and why security exploits are more expensive today than before.

That's how security theater for software works. Today's attackers are well-funded and technically competent. This is a a defense against script kiddies.

The way to get rid of buffer overflows is to get rid of C in trusted code, not requiring users to go through libc. It isn't hard any more. We have Go, Rust, C#, Java, and even node.js and Python for server side. If you're running C in a user-facing server application, you're doing it wrong.

saagarjha18• 7 years ago

Checking should be at the protection boundary, the system call.

This doesn’t make sense, though. This would mean the OS would need to know the control flow of the program itself to figure out whether it “should” allow a system call to proceed.

gpvos• 7 years ago

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.

In which ways is OpenBSD more in control of userspace applications, and in which ways is Linux more loosely coupled?

Switching Go to use the libc wrappers (as is already done on Solaris and macOS)

Did Solaris and macOS also do that for security reasons? (A linked article mentions ABI instability as the reason, but maybe there's more to it.)

monocasa2• 7 years ago

It's just ABI instability. In BSD, Solaris, and MacOS the kernel and libc are distributed by essentially the same people as an atomic unit, and the syscall layer changes over time. On Linux, it's the syscall layer that's stable.

pas3• 7 years ago

It's entirely doable in Linux too. Introduce new syscalls for the new interface, plus one lockdown functionality that disables the old interface so sysadmins/distributions can switch to the new interface. Of course this can and should be coupled with compile time switching, so eventually the old interface will become deprecated, and if no one steps up to maintain it, it will be removed.

It's simply a different approach to doing backward compatibility. (Instead of maintaining very different trees for different versions, the functionality is concurrently available in multiple versions, but with feature switches [compile- and run-time configuration].)

4ad• 7 years ago

Did Solaris and macOS also do that for security reasons? (A linked article mentions ABI instability as the reason, but maybe there's more to it.)

That's all there is to it (I did the Solaris port).

merlincorey• 7 years ago

In which ways is OpenBSD more in control of userspace applications, and in which ways is Linux more loosely coupled?

One of the major differences between Unix and Linux is which parts of the system are in the source tree.

Linux is technically just the kernel, and a Linux distribution will put together the base libraries and userland programs and kernel along with various tools for installing and managing.

Kernel space programs are generally the kernel itself and device drivers.

Base userland programs are things like `cat` and `ls` and more that allow for manipulating and inspecting parts of the system. User-space programs are any userland program which is not in kernel-space, including third party packages and custom software written by the user.

Userland programs need to be linked against libraries, which is where libc comes in.

In most BSD Unix systems, the source tree will include the kernel and the base userland programs together.

That means that OpenBSD's versions of `libc` and `ls` are maintained in the same source tree as the kernel, allowing for much tighter coupling and integration for changes.

By contrast, the Linux distributions are generally using some versions of GNU C and GNU Coreutils, perhaps with patches downstream.

So a core change to the Linux kernel must make its way upstream to the user space application and then downstream from that, the distribution must integrate both.

This is much more loosely coupled and should hopefully illustrate the difficulty in coordinating such a change in Linux.

saagarjha18• 7 years ago

The coupling here is specifically the lockstep of the kernel syscall ABI and libc.

chrisseaton• 7 years ago

In which ways is OpenBSD more in control of userspace applications

They port and package them themselves.

blinskey• 7 years ago

Folks interested in this sort of news might also enjoy the OpenBSD Journal, which covered this recently, albeit more succinctly: https://undeadly.org/cgi?action=article;sid=20191202105849

claudiawerner• 7 years ago

Totally off-topic, but it's interesting how the URL uses ; as the GET parameter separator rather than &.

pas3• 7 years ago

The internal syntax and semantics of the query part is not really defined by HTTP. (https://tools.ietf.org/html/rfc3986#section-3.4)

Also:

"Historic RFC 1866 (obsoleted by RFC 2854) encourages CGI authors to support ';' in addition to '&'"

https://en.wikipedia.org/wiki/URL#cite_note-23

haecceity2• 7 years ago

So what's stopping the attacker from searching the libc export table for the right syscall wrapper?

saagarjha18• 7 years ago

ASLR, for one.

haecceity2• 7 years ago

Can't they use dlopen to find libc?

gok2• 7 years ago

This is a pretty weak security mitigation since any ROP attack will typically achieve return-to-libc anyway, but yelling at people who make syscalls directly is good.

saagarjha18• 7 years ago

I think it might protect against JIT shellcode.

throwaway20485• 7 years ago

You still need an information leak of exact address of a libc function to achieve that, that will be different on every program invocation due to ASLR, and brute forcing is useless on a 64bit memory space. Even information leaks about the location of other less useful libc functions + offset isn't enough, because OpenBSD randomly relinks libc every boot, so just having the libc of a release to harvest offset information isn't useful.

nineteen9997• 7 years ago

but yelling at people who make syscalls directly is good.

Why though? Doesn't this mean that all non-C based languages are going to be treated somewhat as second class citizens, having to link the standard C library (eg. as Go is doing on some platforms) in order to call into the kernel?

While languages such as Go and Rust are aiming to replace/displace C due to it being designed in an age where security was considered less of an issue, it seems counter-intuitive to me that we should insist that they should link in the apparent attack surface of the standard C library. The syscall boundary seems an ideal place to make the delineation between the kernel and userland via an established API, and I would have expected that languages that want to displace C be able to use that interface directly in order to bypass the standard C library. That would seem to allow userlands to be built that include no C code whatsoever. But I'm very obviously no expert.

throwaway20485• 7 years ago

Nothing about this prevents applications from being built that do not depend on libc, this is a flag set on elf binaries that the program loader honors, tooling to build things that really want to generate syscalls can just flag all sections as syscalls allowed.

quotemstr8• 7 years ago

Can you help me explain where this second class citizen sentiment comes from? If all programs need to go through libc, doesn't that mean they are all equal? Whether to make system calls go through libc or not is just a matter of where you put the ABI boundary. Putting that boundary "above" the raw system call instruction (like most OSes do) doesn't hurt anyone. Linux does it differently mostly because it just shipped the org chart.

gok2• 7 years ago

It's totally acceptable to write to libc in something other than C, or in fact to write libc itself in something other than C.

pjmlp9• 7 years ago

OS stable API and ISO C standard library aren't the same thing though, some UNIX just end up mixing both, while others don't even allow documented access to them e.g. Apple one's.

Someone• 7 years ago

"having to link the standard C library”

Ideally, IMO, there should be two libraries, a “Kernel interface library” and a “C library”, but for now, just think of it as two logical libraries in a single file.

quotemstr8• 7 years ago

CFI goes a long way towards defeating ROP

saagarjha18• 7 years ago

Are there any systems that implement widespread CFI for all binaries? The most I’ve seen is glibc’s endbr64 at the top of _start.

badrabbit• 7 years ago

Windows yells plenty and look at how that turned out. Like pitching a tent in a hurricane.

jedisct1• 7 years ago

And then WebAssembly will ruin all these efforts.

saagarjha18• 7 years ago

WebAssembly should not be making direct system calls anyways.

anthk2• 7 years ago

You wish, but Chromium is pledged under OpenBSD.

quotemstr8• 7 years ago

I strongly support this policy not only for security, but also for general operating system robustness. Linux is pretty much the only system that places the ABI compatibility boundary and the machine privilege level boundary in the same place in the stack. I think that's the wrong place: it pushes a lot of complexity that could be in userspace into the kernel, because the kernel is the first place past the ABI break. Linux would be better if nobody except libc were allowed to make system calls and we just made libc (or a giant VDSO) the ABI support boundary.

We should at the very least have a VDSO for every system call. There should be some opportunity to run code in userspace before a privilege transition. Doing so would give us a lot more flexibility than we have now.

For example, consider socketcall(2): for a long time, all Linux socket system calls (like recvmsg) were multiplexed through a single system call. A few years ago, the kernel community realized that this multiplexing was a bad idea and made individual system calls for all the traditional socket operations. But since we have to support old programs, we have socketcall(2) and the new system calls in the kernel. Why should we?

If the ABI support level had been libc all along, we could have changed the system call strategy (from multiplexing to fine-grained calls) transparently without bloating the kernel with compatibility code.

saagarjha18• 7 years ago

We should have a VDSO for every system call.

This doesn't really make sense; the vDSO only works for system calls that do nothing but read a value from the kernel and return it to userspace.

quotemstr8• 7 years ago

Not the case. Some VDSOs just forward to regular system calls. Try clock_gettime with CLOCK_BOOTTIME sometime. (I need to send a patch to fix this. Maybe over Christmas.)

Requiring that every system call go through a VDSO would be great because it would give us a "hook" for changing system behavior before entering the kernel, which is a good thing, because in the age of speculative execution mitigations, entering the kernel is expensive, just like in the days of yore.

me_again• 7 years ago

Wouldn't this make containers way more difficult?

quotemstr8• 7 years ago

Why would it? You need to bootstrap allowed call paths, and whatever init does to do that, PID 1 in a namespace could do that too.

OpenBSD system-call-origin verification

Related Stories