OpenBSD developer, Florian Obser, has written a detailed post on privilege drop, privilege separation, and restricted-service operating mode in OpenBSD. The BSD-derived operating project, OpenBSD, has been at the forefront of mitigation techniques, for decades now. Florian discusses what OpenBSD has now, and how it got there and provides examples.
Prologue
My main focus in OpenBSD are privilege separated network daemons running in restricted-service operation mode. I gave talks at BSDCan and FOSDEM in the past about how I used these techniques to write slaacd(8) and unwind(8). While I do not think of myself as a one-trick pony, I have written some more: slowcgi(8), rad(8), dhcpleased(8), and gelatod(8). I also wrote the first version of what later turned into resolvd(8).
At one point I claimed that it would take me about a week to transmogrify one daemon into a new one.
Why
Privilege drop, privilege separation, and restricted-service operating mode are exploit mitigations. When1 an attacker finds a bug we try to stop them from causing damage. The mitigations we are talking about here are aimed at attackers that achieved arbitrary code execution. Due to other mitigations that is quite difficult to pull off. These are the last line of defence. We try to remove as many resources from the attacker to play with and try to crash the program as quickly as possible if an attacker touches something they are not supposed to.
Previously:
(2022) Fuzzing Ping(8) ... and Finding a 24 Year Old Bug
(2021) Recent and Not So Recent Changes in OpenBSD That Make Life Better
(2018) OpenBSD Chief De Raadt Says No Easy Fix For New Intel CPU Bug
(2017) Kernel Address Randomized Link in OpenBSD
(2014) Bob Beck gives a 30-day status update on LibreSSL
And many more.
« Germany Raises Red Flags About Palantir’s Big Data Dragnet | Majority of Ransomware Attacks Last Year Exploited Old Bugs »
Related Stories
Bob Beck who is an OpenBSD, OpenSSH, and LibreSSL developer as well as the director of Alberta-based non-profit OpenBSD Foundation gave a talk earlier today at BSDCan 2014 in Ottawa, discussing and illustrating the OpenSSL problems that have led to the creation of a big fork of OpenSSL that is still API-compatible with the original, providing a drop-in replacement, without the #ifdef spaghetti and without its own "OpenSSL C" dialect.
Bob is claiming that the Maryland-incorporated OpenSSL Foundation is nothing but a for-profit front for FIPS consulting gigs, and that noone at OpenSSL is actually interested in maintaining OpenSSL, but merely adding more and more features, with the existing bugs rotting in bug-tracking for a staggering 4 years (CVE-2010-5298 has been independently re-discovered by the OpenBSD team after having been quietly reported in OpenSSL's RT some 4 years prior).
Bob reports that the bug-tracking system abandoned by OpenSSL has actually been very useful to the OpenBSD developers at finding and fixing even more of OpenSSL bugs in downstream LibreSSL, which still remain unfixed in upstream OpenSSL.
It is revealed that a lot of crude cleaning has already been completed, and the process is still ongoing, but some new ciphers already saw their addition to LibreSSL RFC 5639 EC Brainpool, ChaCha20, Poly1305, FRP256v1, and some derivatives based on the above, like ChaCha20-Poly1305 AEAD EVP from Adam Langley's Chromium OpenSSL patchset.
To conclude, Bob warns against portable LibreSSL knockoffs, and asks the community for Funding Commitment -- the Linux Foundation is turning a blind eye to LibreSSL, and instead is only committed to funding OpenSSL directly, despite the apparent lack of security-oriented direction within the OpenSSL project upstream. Funding can be directed to the OpenBSD Foundation.
https://marc.info/?l=openbsd-tech&m=149732026405941&w=2
https://marc.info/?l=openbsd-tech&m=149732265506347&w=2
There is now scaffolding to ensure booting to a newly-linked kernel for every reboot. New random kernels can be linked together, automatically in the background by the rc
scripts, and installed as /bsd. On a fast machine it takes less than a second. A mail is sent to the system administrator. A reboot runs the new kernel, and yet another kernel is built for the next boot.
From Theo de Raadt's email to the list:
Over the last three weeks I've been working on a new randomization feature which will protect the kernel.
The situation today is that many people install a kernel binary from OpenBSD, and then run that same kernel binary for 6 months or more. We have substantial randomization for the memory allocations made by the kernel, and for userland also of course.
However that kernel is always in the same physical memory, at the same virtual address space (we call it KVA).
Improving this situation takes a few steps.
Recently I moved all our kernels to a new mapping model, with patrick and visa taking care of two platforms.
Previously, the kernel assembly language bootstrap/runtime locore.S was compiled and linked with all the other .c files of the kernel in a deterministic fashion. locore.o was always first, then the .c files order specified by our config(8) utility and some helper files.
In the new world order, locore is split into two files: One chunk is bootstrap, that is left at the beginning. The assembly language runtime and all other files are linked in random fashion. There are some other pieces to try to improve the randomness of the layout.
As a result, every new kernel is unique. The relative offsets between functions and data are unique.
[...] Our immune systems work better when they are unique. Otherwise one airline passenger from Singapore with a new flu could wipe out Europe (they should fly to Washington instead).
Our computers should be more immune.
[Editors note: This is a couple weeks old now, but was by far the best tech story I could find in the submission queue]
Recompiling is unlikely to be a catch-all solution for a recently unveiled Intel CPU vulnerability known as TLBleed, the details of which were leaked on Friday, the head of the OpenBSD project Theo de Raadt says.
The details of TLBleed, which gets its name from the fact that the flaw targets the translation lookaside buffer, a CPU cache, were leaked to the British tech site, The Register; the side-channel vulnerability can be theoretically exploited to extract encryption keys and private information from programs.
Former NSA hacker Jake Williams said on Twitter that a fix would probably need changes to the core operating system and were likely to involve "a ton of work to mitigate (mostly app recompile)".
But de Raadt was not so sanguine. "There are people saying you can change the kernel's process scheduler," he told iTWire on Monday. "(It's) not so easy."
Consultant and author Peter N M Hansteen has written up an overview of recent and not so recent changes in OpenBSD that make life better (and may turn up elsewhere too). He covers a few decades of developments that he has found particularly useful and explains why. He covers greylisting, spam filters, OpenSSH, and of course PF.
When I found OpenBSD more than twenty years ago, my main Unix exposure was from working with Linuxes and FreeBSD. What attracted me to OpenBSD and finally had me buy an OpenBSD 2.5 CD set was the strong focus on security and code correctness. When the CD set and the classic wireframe daemon T-shirt finally arrived in the mail, I set about at first to install it on whatever spare hardware I had lying around.
[...] OpenBSD has had traffic shaping available in the ALTQ subsystem since the very early days. ALTQ was rolled into PF at some point, but the code was still marked experimental 15 years after it was written, and most people who tried to use it in anger at the time found the syntax inelegant at best, infuriating or worse at most times.
So Henning Brauer took a keen interest in the problem, and reached the conclusion that all the various traffic shaping algorithms were not in fact needed. They could all except one be reduced to mere configuration options, either as setting priorities on pass or match rules or as variations of the theme of the mother algorithm Hierarchical Fair Service Curve (HFSC for short).
Soon after, another not-small diff was making the rounds. The patch was applied early in the OpenBSD 5.5 cycle, and for the lifetime of that release older ALTQ setups were possible side by side with the new queueing system.
OpenBSD is a complete operating system and originally forked from NetBSD back in 1995 which forked from 386BSD which was ported from 4BSD. It's emphasis is on portability, standardization, correctness, proactive security, and integrated cryptography. The current release, 6.9, is its 50th release.
Previously:
(2020) Using OpenBSD Routing Tables to Segment the Home Network for Privacy
(2020) The OpenBSD Project's 25th Anniversary
(2020) WireGuard Imported Into OpenBSD
(2017) OpenBSD and the Modern Laptop
and many more...
OpenBSD developer, Florian Obser, has written about fuzzing ping(8) and finding a 24 year old bug. The utility ping(8) is about the simplest networking utility there is and it has been around in one for or another since the early 1980s. Yet some things were hiding which were exposed by running the Afl fuzzer:
Afl uses files to feed data to programs to get them to crash or otherwise misbehave. I had wondered for a few years how I could use afl with things that talk to the network. Because that's what I mostly work on. In hindsight it's quite obvious. You identify the main parsing function, wrap it in a new main() function and Robert is your father's nearest male relative.
The two main takeaways from this are: One, if someone messes up somewhere, go look if you messed up in the same or similar way somewhere else. Two, afl is pretty easy to use, even for network programs. 30 minutes from reading about afl for the first time to finding a bug in a real world program is pretty neat.
Next up, cat(1) ?
Via Undeadly.
(Score: 4, Informative) by bzipitidoo on Tuesday February 21, @01:04PM (4 children)
The article is pretty technical, and you need considerable knowledge of UNIX/POSIX to fully understand it. Still, I believe I got the gist of it, which is that OpenBSD has added several tools to support a reduction of system access of the utilities common to many different UNIXes. The default is that a binary with root privileges has access to everything and can do anything at all.
In their example, ping needs root access to use the network. But root also gives a utility the power to access files, and ping doesn't need that. So they've added ways for the utility itself to ask that its access be reduced. Then they modify ping so that it uses these access reduction tools. They pushed the access reduction as close to the start as possible.
The whole idea is that if ping has a flaw that a malformed packet can exploit, by the time ping has set itself up to communicate over the network and receive and process a packet, it has already reduced its own access so that a successful exploitation that takes control of ping cannot use ping to do much.
How good an idea is all this? Seems a pretty good idea, but I don't know. It adds one more thing a developer ought to know about, and every year, there's more and more such things to track. Is sanitizing input really so hard? The whole thing is basically a failsafe, just in case sanitizing missed something.
Also, I am dubious about where this burden is placed: in the utility itself. Suppose it is possible for a two step attack, in which the first step is to compromise the utility so that it fails to reduce its privileges the next time it is invoked, then, when that next invocation finally happens, and it receives the next malicious payload, it pwns the system? Shouldn't access restriction be done in a more SELinux fashion? Or at the least, lifted from runtime to compile time, so that the ping binary comes equipped with flags that tell the kernel to give it only network access?
(Score: 3, Interesting) by Mojibake Tengu on Tuesday February 21, @02:15PM
Unix root absolutism is the most stupid thing invented ever. Anything demented like this was unthinkable on mainframes.
I appreciate the pledge syscall concept, though it's only a treatment, not cure.
It's relatively easy to workaround by two or several cooperating hacked processes, so it increases hacking complexity by only a polynomial factor.
The edge of 太玄 cannot be defined, for it is beyond every aspect of design
(Score: 1) by shrewdsheep on Tuesday February 21, @08:48PM
Sounds similar to AppArmor. It would seem more sensible to me to put the permissions into a config file (like AppArmor does) instead of putting it into the application.
(Score: 2, Interesting) by Anonymous Coward on Wednesday February 22, @01:05AM
But how would you do that? If you could change the executable in the OS you already have the privileges to compromise other stuff.
If you are trying to compromise it by exploiting a bug in it while running it, if it's already dropped its privileges before it reaches that bug, it won't have the privileges to change itself or do other stuff.
(Score: 2) by bart9h on Wednesday February 22, @04:29PM
It's not only about the sanitizing logic missing something, but also those pesky memory bugs that can lead to exploits.
(Score: -1, Offtopic) by Anonymous Coward on Tuesday February 21, @03:46PM (1 child)
So what kind of privilege was it? White? Male? If not it just doesn't count.
(Score: -1, Informative) by Anonymous Coward on Tuesday February 21, @07:14PM
What about incel privilege?
Why does no one ever think of the pasty incels sitting in their Mom's basement? Don't they know fat is beautiful? Three hundred pounds is glorious; four hundred pounds is even better!
Don't they know those incels are entitled? Why is the world is so unfair? Please, please send more Doritos!