OpenBSD system-call-origin verification
lwn.net
lwn.net
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.
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.
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.
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.
Hint: having some security and mitigations makes it less likely for an attacker to start with such capabilities.
If someone can show this is done by configuring the local dynamic linker, so that the end user has full control of the mechanism, then I'm all ears.
It's trying to mitigate exploits, but if your attacker is already running arbitrary code, they don't need those exploits. They're way past that phase.
This feature is yet another layer of defense against remote exploitation of a currently running program (for example, a web browser). It complements things such as ASLR, stack canaries, the NX bit, ...
> If all programs need to go through libc, doesn't that mean they are all equal?
It means that all programs need to link libc into their binary, whether statically or dynamically. Part of the reason-de-etre for Rust seems to be as a replacement for C and C++ so it would seem peculiar to me that the C library would become a forced dependency for compiled languages like those. But as the other poster pointed out, you can disable it anyway, so no matter.
As for static libc: please don't do this. A static libc, from a compatibility POV, is just as bad as embedding random SYSENTER instructions in program text. It makes the system much more brittle than it would otherwise be. I understand the desire to package a whole program into a single blob that works on every system, but we should support this use case with strong compatibility guarantees for libc, not with making SYSENTER the permanent support boundary!
When I am god emperor of mankind, on my first day, I will outlaw both static linking of libc and non-PIE main executables.
Preaching to the converted here, I'm a big fan of dynamic linking. It seems that while Go binaries are generally statically linked (last time I checked, which was a while ago), that libc is generally dynamically linked for the reasons that you have stated, also also because some features like NSS require dynamic linking to work correctly.
Disclaimer: I mostly program in C and C++, not Rust or Go (yet).
> Current Status - llvm-libc development is still in the planning phase.
Thankfully Apple, Google, IBM and Unisys seem to be on the same boat.
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.
$ annocheck -v /usr/bin/ls
[...]
Hardened: /usr/bin/ls: PASS: Compiled with -fcf-protection.Also:
"Historic RFC 1866 (obsoleted by RFC 2854) encourages CGI authors to support ';' in addition to '&'"
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.)
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].)
"You don't break userspace". How many decades until people who no longer have source for the broken binaries that they run will stop complaining?
How long until sysadmins know to turn the knobs on?
How many knobs are sustainable? How much will they interact, and in how many ways will those interactions expose vulnerabilities?
The Linux way to introduce this is hell for everyone involved.
How many? Dunno, doesn't matter. If there are users they are usually willing to step up to maintain it, and that makes having parallel APIs not a problem (the old one becomes a wrapper).
Furthermore UNIX/BSD faces the same problem with every other program that lives out of tree. (Which is the majority of them anyway.)
Knobology is always an endless debate, yet also regularly done without much fuss, usually simply by what the maintainer(s) decide to provide.
Standard Linux drivers are considered legacy, with all new drivers using their own processes talking via Android IPC.
Userspace is all about Android Java, ISO C, ISO C++, and NDK APIs, everything else is considered off hands and there is also some gatekeeping via LinuxSE, securecomp of whatever else is allowed.
Only Android OEMs get to publish drivers.
That's all there is to it (I did the Solaris port).
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.
They port and package them themselves.
Just half trolling.
An OS that happens to expose some support for POSIX, yeah (e.g. Redox), but anything else wouldn't be an UNIX clone per se.
Modern software is sidestepping the UNIX way left and right. Rightly so, as anyone who's tried to write anything serious in shell would know. Or anyone who realizes that non-blocking I/O was an afterthought (look into the history of select(2) and why libraries like libev exist and what problems they run into on unix derivatives..) and that there's still nothing like a standard, robust, well designed async I/O API.
History would be quite different if AT&T was allowed to sell it from day one.
(Oh, double checked, and uh, maybe. ld.so does treat libc specially if it finds it in the library list, but at that point, you are linking with libc. But afaik there's no requirement you use the system ld.so either.)
They are designed as a protection against stuff like ROP and other memory based, zero information attacks that hit already running processes.
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.
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.
The problem is buffer overflows. Fix that, and you don't need ASLR. ASLR is a form of security theater. It protects against dumb attackers.
[1] https://threatpost.com/bypassing-aslr-in-60-milliseconds/121...
On x86 clones Intel just dropped the buggy MPX, with no replacement in sight.
And by the way things are going, any form of Safe C variant, doesn't appear to ever be adopted by UNIX clones.
Let's ignore that only recently have languages become available that make it possible to do so for high-performance code. That's a straightforward problem to solve - we know how to rewrite code in other languages, we can build tools to help us do it effectively, etc.
Let's also ignore that the recency of the languages mean that few people know how to code that effectively. We can train armies of engineers.
Let's ignore that training engineers takes significant amounts of time & shifting massive industries is difficult. That will be solved over time.
Lets ignore that Rust is more difficult to write than C/C++ - after all we're just converting existing code so that could be easier & the more time spent during writing is paid off by less time debugging at runtime.
Let's also ignore that A LOT of money has been poured into existing software and a non-trivial amount would have to be donated/volunteered to migrate to languages where it's impossible. We have OSS volunteers and enthusiasts and corporate interests are aligned to sponsor conversions.
Let's ignore that it takes time to integrate new languages into large corporations with existing build systems, infrastructure, tooling, etc. They'll solve that - again, interests are aligned here.
Let's ignore ALL of those issues. XSS, Rowhammer, Meltdown, Specter, downgrade attacks, man-in-the-middle, spear phishing, bugs in cryptographic algorithm design, side-channel attacks, etc are all still security attacks that have very real, and perhaps sometimes more serious, consequences than buffer overflows and waving a magic wand and fixing all buffer overflows wouldn't really adjust the security landscape we deal with today (maybe exploits would get more expensive - maybe, but ASLR et all do that too).
Following the same logic you laid out, this focus on buffer overflows at all is just security theater: ASLR is to buffer overflows what buffer overflows is to all security bugs overall. Back in reality ASLR, syscall origin verification, etc are all tools to try to mitigate the impact of all the things we ignored above & we know they have an impact because exploits keep getting more expensive, the low-hanging fruit bugs always get patched quickly, etc.
So sure, once the world has switched to Rust and we can turn off all these other protections that make buffer overflows more difficult. Oh, except we can't because now we remember that Rust has "unsafe" & that's used A LOT for various reasons. So now you need those protections anyway in case there's a bug in the unsafe code. And I 100% promise you there will be exploits there or in the Rust compiler. We can have confidence this will be the case because it's already happened: https://medium.com/@shnatsel/how-rusts-standard-library-was-..., https://blog.rust-lang.org/2019/11/01/nll-hard-errors.html). So your claim that we know how to fix buffer overflows is just inane even on its face. Hell, this isn't even a Rust-specific thing. I would be very skeptical if you could find a single semi-popular language without a buffer overflow bug of some kind somewhere, even in managed languages. The Java VM is full of them. Go has them. etc.
TLDR: You may want to reexamine your arrogance. Security is an extremely hard topic that will never get solved. Are there shitty programmers? Sure. Are security problems exclusively written by them? No. Security issues are an emergent property of complex systems. Some are easy to solve once and for all once the root cause is known. Others are MUCH harder.
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.
Note we are talking about exploit code here, i.e. you have just exploited a buffer overflow, not ELF code loaded in a well behaved fashion.