Seems to be found as a part of Patch The Planet [0] which is basically OpenAI giving model access and Trail of Bits using them to find vulnerabilities in OSS projects.
dnsmasq: Codex Security independently identified vulnerable patterns corresponding to four of the six dnsmasq CVEs later fixed in 2.92rel2: CVE-2026-4890 (opens in a new window), CVE-2026-4891 (opens in a new window), CVE-2026-4892 (opens in a new window), and CVE-2026-517
dnsmasq has had so many freaking security holes in 2025 and 2026 that atm I decided to just remove that thing from all my machines.
Unbound can do authoritative dns. It is a bit clunky so usually what you do is have NSD for the authoritative parts and unbound for the recursive parts. but unbound has local-zone: stub-zone: forward-zone: auth-zone: directives. I am not the most sophisticated dns admin but I am fairly sure that just unbound by itself can do almost any dns party trick you care to throw at it.
I use NSD myself, but the man page sez an auth-zone directive could act like a self contained authoritive zone served from a file. the other way it can be used to to speed up the cache for the actual authoritive data.
"Authority zones are configured with auth-zone:, and each one must have a name. There can be multiple ones, by listing multiple auth-zone section clauses, each with a different name, pertaining to that part of the namespace. The authority zone with the name closest to the name looked up is used. Authority zones can be processed on two distinct, non-exclusive, configurable stages.
With for-downstream: yes (default), authority zones are processed after local-zones and before cache. When used in this manner, Unbound responds like an authority server with no further processing other than returning an answer from the zone contents. A notable example, in this case, is CNAME records which are returned verbatim to downstream clients without further resolution.
With for-upstream: yes (default), authority zones are processed after the cache lookup, just before going to the network to fetch information for recursion. When used in this manner they provide a local copy of an authority server that speeds up lookups for that data during resolving.
If both options are enabled (default), client queries for an authority zone are answered authoritatively from Unbound, while internal queries that require data from the authority zone consult the local zone data instead of going to the network.
An interesting configuration is for-downstream: no, for-upstream: yes that allows for hyperlocal behavior where both client and internal queries consult the local zone data while resolving. In this case, the aforementioned CNAME example will result in a thoroughly resolved answer.
Authority zones can be read from a zonefile. And can be kept updated via AXFR and IXFR. After update the zonefile is rewritten. The update mechanism uses the SOA timer values and performs SOA UDP queries to detect zone changes."
One bug found is a testament to the great diligence and culture around security of OpenBSD. Especially if you take into account the amount of resources they have been able to achieve this with.
It is also a testament to solid engineering and attention to good security practices in general. These still work, also against fancy new AI attackers.
When sophisticated attacks become cheaper to run, maybe it will (finally) be cheaper to do more solid engineering instead of doing it quick and dirty and ending up in indefinite bug-squashing mode.
I suspect the easier option is to use AI to review your own code. The arms race between developers and attackers might even make some of the AI valuations come true.
You're right, but of course OpenBSD does far more than 20%.
One thing I actually really like about OpenBSD is that things either work or they don't. There's no "Well it kind of works if you have this specific hardware set up and these programs running..." It just works 100% of the time, in 100% of the ways you expect, or it doesn't.
That does not match my experience with obsd. It is not so much minimalism as they are not afraid to reinvent the wheel. A obsd install is full of services, more than most linux installs I have seen.
For example you can imagine my disappointment when I discovered what a pain in the ass it is to get a pflow producer working on linux after doing the first one on openbsd.
And as a counter example here you have openbsd "we are going to install a bgp daemon on every single device, because you never know when you may need one"
I am not complaining, I like the feeling that I could single handedly rebuild the internet using only what is found in an openbsd base install. But wow, considering the size there is a lot in there. They definitely punch above their weight.
It's not a counter example to give examples of what does exist.
And it's not like the BGP daemon is on by default. That'd be dumb. You could equally say that any Ubuntu system has equally many steps to turn on a BGP daemon, starting with `apt install frr`.
I sure hope openbsd's BGPd doesn't have any suid binaries. And if it doesn't, well that might just as well be a vacation photo instead of a binary for all the "code" it is.
I agree that they're punching above their weight, but I would also say that they are falling more and more behind. 25 years ago they were more at par in what use cases they can address, and its performance. But now it's almost retro computing.
And it's fine! If you really only need a bog standard webserver, or router/firewall, then that's the use case and it solves your problem. And solves the problem without baggage.
I wouldn't use it for storage, though, since running a non-checksumming filesystem nowadays is a bit of a joke. (let's not get into btrfs. I acknowledge its history, but checksumming is not backups, and backups address the historical btrfs problems while not addressing at all the checksumming)
But Bluetooth is basically a giant blast of security vulnerabilities. On the consumer side, yes, it's a big subsystem to drop, but on the server side, it's a little bit different!
I'm not an OpenBSD expert, but seems like you should be able to pass BT through USB and then do that in a subsystem or an isolated environment like a VM.
> But Bluetooth is basically a giant blast of security vulnerabilities
Yes, but this is exactly the point. And running OpenBSD is not a problem, until you run into a brick wall like this.
If you don't need it (and things like it), then that's all fine. As with everything, the last 10% takes 99% of the work, and code, and therefore contains about 99% of the security problems.
IIRC they were also very late to being able to run virtual machines, and even USB.
If you simply don't implement the things you don't need for a use case (e.g. a webserver) then that scales down to the fact that the compressor controller chip in your (dumb) fridge is not remotely exploitable too.
The Bluetooth spec is horrendous, and from what I read, the hardware is equally horrifying. Bluettoth is a wireless bus, not one class a device and an implementation would need to provide hooks to the other subsystems like wscons (keyboard and mouse), audio and network. OpenBSD does not have kernel modules, so it’s either in or not.
The Bluetooth Classic spec is indeed fairly awful, but the Bluetooth LE spec is not too bad. Plus, the entire specification is available free-of-charge, without even needing to register an account.
Bluetooth LE used to be limited to tiny accessories, but these days it supports nearly everything—I've completely disabled Bluetooth Classic on my (Linux) laptop because of how much of a disaster it is, but I'm still able to use my mouse and headphones over LE only.
> OpenBSD does not have kernel modules, so it’s either in or not.
But I'm assuming that not all kernel code is active at all times? Because it would seem odd to me if the amdgpu code was always active on something like a Raspberry Pi.
There’s a config[0] mechanism, both static and runtime that tells what gets enabled. In static mode, it tells what’s get compiled in the kernel, while you can disable any drivers (and save your config as a modified kernel) in a compiled one.
It mostly a drivers tree that describe how to probe for hadrware. Like mainbus -> pci -> xhci -> usb -> uaudio -> audio.
Depends on what you mean by active. The kernel has the code in the binary, but on boot it goes through device discovery and initialization, so it doesn't initialize or run drivers for things that aren't present.
There are also architecture specific builds, so the aarch64 build won't include driver code at all for devices that are specific to x86.
I ran it diskless for years with read-only NFS mounts. Set up syslog and a pflog daemon to send logs elsewhere, and you don't need write access most of the time.
I believe that while the file system does not have journaling, that can be offset by applications. I.e. I think the SQLite Write Ahead Log would still protect you against data loss even if there's no journal in the file system, assuming you set various settings correctly. So I think it kinda depends on how the applications store data.
OpenBSD's FFS can be told to be fully synchronous, making it about as robust as can be for not being journaled. If you lose power it will lose the specific data currently being written to disk. It won't lose other data, because it doesn't keep a bunch of it sitting around in a RAM cache while lying to the writing process about the I/O op already being completed. A journaled file system, too, will lose in-flight data that has yet to land on disk if the power is cut.
I've had my share of sudden power cuts hit OpenBSD during the 20+ years I've been using it, and I have yet to ever see its file system actually go corrupt.
A sincere question: what important data does your router frequently and busily need to persist? If you don't have a UPS for it, perhaps it isn't too important after all. Maybe we have different perspectives of what a router is and should be. I manage a router (with OpenBSD) and it can drop off the power grid at any moment without losing anything of importance. If your router is in fact a multi-functional server I can understand the notion. Consider making all of the file systems fully synchronous. It has worked great for me for two decades.
If they can provide only 20% of the functionality and only 1% of the bugs, that's a compelling trade-off for many use-cases! (and a bit closer to the reality IMHO)
Exactly, the entire AI industry has been trying to create an AI powered security arm race. I am not necessarily blaming them.
Hard to know how much has been thrown into this but I would bet a lot.
So far I have been very surprised we haven't been flooded by those type of announcements. If you look you will always find something and OpenBSD is the top price.
They are throwing tokens at codebases and finding mostly vulnerabilities in cases that have not been worth the limited time and effort of the chronically underfunded and understaffed professional groups. There’d be a lot more value in the companies giving the money they spend on their synthetic text extruders to the organizations doing quality security research work.
The point of the comment you are replying to is that it's also not worth the time and effort to use LLMs to find vulnerabilities, if "time and effort" can be measured with "money". If you factor in all the money spent on training, GPU data centers etc, it's not actually a financially efficient way to find bugs unless you profit from creating demand for LLMs. LLMs aren't cheaper than humans per unit work, yet. They're just massively deficit funded because capital thinks "AI" is going to reshape the world order, and wants in.
I don't think that's true? It runs most services as their own separate users, with pledge+unveil to limit what they can access even more. That's very much depth.
It is true. The do surface level protections, but have nothing to really lock down a system. What do they provide that can restrict an attacker who managed to compromise a remote service that wasn't using pledge or unveil? On other OS's, you can set things like append only, limit files being readable by particular processes, whitelist paths or executables from where the system may execute, etc etc etc.
yes, most company settings don't run untrusted code, and OpenBSD is mostly used for servers not employee devices
but that doesn't mean LPEs aren't quite relevant, because they matter for pretty much everyone if combined with other vulnerabilities, like RCE, supply chain attack etc.
and while RCE are becoming less common, supply chain attacks have been increasingly more common
OpenBSD's security stance being the stuff of legend, I'm curious how many vulns have been found over the last couple months while the big model companies are flaunting their ability to find exploits. It'd be super cool to see it remain tiny.
How many times do you see a bug investigation and it's determined when the bug was introduced?
Do you ever look at the diff that introduced it to understand what was going on in the project at the time? Often, it's in service to a new feature. Sometimes the original change is questionable when you consider you traded it for a severe bug.
Yes necessarily. Always. You need to invoke Nasa and fighter jets to find anything coming close, and they only manage to do any better by massive brute overkill in standards & procedures.
Linux is a much larger project receiving changes to tons of systems from lots of different sources. The combined behaviour of those things working together is massively harder to understand and test.
Copyfail being introduced by an optimization made to some random crypto module is a good example of this.
The others and I, working on GNU coreutils, frequently use 'yes' to generate a bunch of garbage input for testing programs. It is nice that it can do so quickly.
Just as another point of comparison, FreeBSD's version seems somewhere in-between. It also enables a Capsicum sandbox before processing any data, akin to what the OpenBSD version does with pledge.
Difference is that capsicum is after the fact and mostly about file descriptors. You need to open them in advance and _then_ call capsicum. But it does nothing about syscalls.
Capsicum is really nice if you plan ahead, but pledge/unveil is easy to drop into any existing code base.
Your blog isn't loading at the moment, so I'm not entirely sure what you mean here, but...
> capsicum is after the fact
After the fact in what sense? The program enters capability mode before touching any arguments or doing I/O. You have to set things up before enter capability mode because you can't escape out of it afterwards.
> it does nothing about syscalls
It does quite a lot about syscalls, in that it blocks or limits most of them. As the man page says: "Access to system calls in capability mode is restricted: some system calls requiring global namespace access are unavailable, while others are constrained."
In capability mode, you can use specific syscalls that operate on file descriptors, which limits the program to the specific capabilities it has been granted, e.g. pdkill(2) which is like kill(2) except you can only signal processes for which you have a process descriptor.
It is quite possible that Linux is the bigger target so it gets more focus. Vulnerabilities there are generally considered more valuable and notable. It would be very difficult to use these numbers to get a meaningful "more secure" stance as there are tons of variables.
From a quick search, Linux kernel is ~40 million loc, freebsd ~9 million, openbsd ~3 million. Number of bugs compared to lines of code leaves FreeBSD looking worse than Linux.
I assume those are lines of code in just the kernels.
As an FYI to everyone: The OpenBSD and FreeBSD teams both maintain entire distributions, similar to Linux + Debian or Linux + Redhat. The OpenBSD team also owns a number of other projects - everything from OpenSSH to PF, OpenBGPD, OpenNTPD, OpenSMTPD, OpenIKED, LibreSSL, pledge and unveil, their own set of perl patches, etc.
I'd say that less lines of code seems to correlate with less bugs in absolute numbers, which works out as more secure for those who don't need the extra code.
Linux also has a ton of extra functionality so I think you’d also have to do some adjustment for “as a user would I be at risk?” versus “can I be a user because it supports my needs?” Some of that would be unfavorable for many users (e.g. a Linux user who is exposed due to a network protocol or file system they’ll never use) but that’s certainly not true of every feature.
That cuts both ways, though. If the functionality is present by default but I'm not using it, that's just extra vulnerability surface. (Of course, if I do want that feature, then its absence is kinda a problem)
Linux also has a ton of bloat. Configuring your own kernel has become an exercise in frustration because documentation is worse "There is no help for this kernel option" and a lot of things are enabled "by default".
Yes, that’s why I wrote the second sentence. However, it’s quite an exaggeration that it’s super hard to configure a kernel - distributions can do that for you (e.g. Amazon Linux disabled a bunch of drivers for hardware you’ll never have in EC2), modules can easily be disabled (common remediation for those IPsec accelerators earlier this year), and it’s not that hard to build your own kernels and distribute them on most popular distributions.
If this is just counting the kernel, than Linux is probably a bigger target both i terms of current code size and the amount of churn in the codebase as things change over time. Some of the LPEs might (I've not checked) be in modules that are not commonly loaded, which mitigates their overall significance somewhat.
In the less likely even that this is counting what laymen would call Linux or BSD, i.e. both the kernel and common libraries & tools, then Linux definitely has a wider attack surface. Though some of that surface is shared as some userland parts are common to both.
As with your assessment, I'd agree that these flat numbers without looking for further context don't really give enough for a one-is-more-or-less-secure statement.
I think of it more as their attention to quality in their code:
Given the 'quality' of most code, especially under commercial pressure, it's no surprise that much more effective tools will find many more vulnerabilities. Did OpenBSDs quality approach work in this respect?
A local escalation in BSD is still apparently worth a front page post here, so that seems pretty good.
I wonder why we don’t see more about local escalations in Windows. Of course, being closed source is a little bit of a barrier, but these tools can read assembly pretty well, right?
I’ve heard a couple people say that Microsoft has patched a record number of bugs internally this year so it might be the case that it’s simply more opaque because it’s initiated internally and doesn’t involve a public Git repo or a third-party researcher.
You don't hear about them because you're probably not paying attention to where all the Windows admins hang out. Nearly every single patch tuesday over the past couple of years has been an emergency race to get things patched as soon as you can, for both local and remote exploits.
I'm not actually, because I'm damn sure I've never seen a piece of openbsd marketing in my life. All i know is that they're oriented around security and are notorious about rejecting patches.
Is this functionality accessible from sandboxed processes? That would make a remote hole much more dangerous when one is found, anyway. The CVE seems to concern SysV semaphores and the pledge(2) man page doesn't seem to mention those.
Perhaps relevant, Students from the University of Southern Denmark released a paper earlier this month, which once again noted the fact that over ~90% of the OpenBSD base system uses pledge(2). Almost certainly all of the network speaking daemons in base do.
sys/kern/sysv_sem.c in OpenBSD through 7.9 has a use-after-free allowing local privilege escalation to root. This is a context switch use-after-free after tsleep in sys_semget().
They appreciate technical correctness and they do not exaggerate. Most 'security researchers' are not technically correct and they exaggerate a lot (seeking fame and all).
Dismissing their claims is not being selective, it's just the right thing to do.
Exactly! As an open source developer who has a notable-enough-for-Wikipedia 25-year-old project out there (MaraDNS), let me tell you, a lot of “security bugs” found by AI-assisted researchers are anything but security bugs. Just some examples of stuff which ended up in my inbox recently:
- A security “bug” where someone who sends hundreds of millions of spoofed DNS queries could possibly have one come through. This is a problem with the DNS protocol, and it’s a problem with broken servers which drop DNS packets under some circumstances. It’s a long known issue where, in reality, the exploit isn’t incredibly practical (to say the least).
- A security “bug” where someone saw `strcat` in my code and assumed it was automatically a big huge buffer overflow exploit. No, it wasn’t: I did bounds checking in all cases, except one case where the program in question hasn’t been able to even compile since 2022 (and is a side utility which isn’t needed in any way, shape, or form to run MaraDNS).
- A bunch of security “bugs” which were cases where my recursive resolver took a few seconds to fully drop resources used to solve a DNS query if it got various kinds of weird packets. This researcher claimed one bug was a remote packet of death, so I spent an entire afternoon writing a test case creating the packet in question. Nope, no packet of death.
- Finally, one researcher did find a security bug in the TCP code for the recurisve resolver, where an authorized client could disable the TCP server (without affecting the UDP server). Keep in mind that the code doesn’t enable TCP by default, a user would have to go out of their way to enable DNS-over-TCP, and it’s not a “packet of death” because the IP sending the bad TCP packets has to be one already authorized to perform recursive queries.
With the DNS-over-TCP bug, I patched the code and made a new MaraDNS release. With the overflow in the code which hasn’t compiled since 2022, I fixed the bug, patched the code to compile again, then next removed the code completely from MaraDNS (putting it in “MaraDNS-attic”).
As an aside, djbdns users may have observed that, because of the C23 changes, djbdns doesn’t even compile anymore, and I am not aware of anyone besides myself caring enough to post patches. In my own distribution of djbdns, I have instructed people to set CC to "c99 -D_DEFAULT_SOURCE" so that the code can compile again.
The fact that most security researches tend to bullshit to pump up their numbers doesn't mean that OpenBSD isn't selective.
The main claim from OpenBSD is "Only two remote holes in the default install since forever".
It is technically true. But it's also selective because they deliberately disable every service by default and don't install any software beyond core.
Once the OS is configured to be useful, we're far from the default install and they would (and have!) refuse to update their motto when confronted with RCEs in those parts.
Which is fair enough! You gotta draw the line somewhere. But that's still being very selective.
> they deliberately disable every service by default and don't install any software beyond core.
Do you prefer that or everything (or most/many services) being enabled by default? It's a good practice and, for me, very practical - I don't need to find everything I'm not using and disable it.
Nobody is saying that their minimal default install is itself problematic.
But trumpeting your default install's safety record doesn't actually say much when the default install doesn't actually do anything. As soon as you add a package or a port you're beyond "default install" territory and their vaunted security reputation's coverage.
I think we agree except one point: IMHO the security of their default install is worth trumpeting: disabling by default is not a technical wonder, but it's good security that others don't do.
Would Rust have made this issue impossible by construction? I know Linus has spoken about Rust's promises about memory safety not being equivalently applicable in the kernel domain, so I would be curious to hear any kernel developer's perspectives.
I'm not a kernel developer but I am an embedded firmware engineer.
To be clear: I like Rust. It's great, I use it a lot. But, Rust's memory safety stuff can't really save you from the screwiness of ISRs. Here's a long-winded example:
ST has a nifty double-buffer DMA mode for their ADCs, so you can give the ADC two different buffers, it'll fill one, fire an IRQ, you catch the IRQ and handle the data, meanwhile, it's filling the other buffer, and the IRQ fires again, you handle the data in the other buffer, rinse, repeat.
This allows the ADC to run continuously, monotonically and at very high sample rates, without monopolizing CPU. It's really a terrific design. I used it for a DIY telephony project once to run continuous FFTs on several ADC channels at once.
This is all fun, but the architecture introduces synchronization issues that aren't immediately solvable within Rust's data model.
Okay, so I can't run the FFT from within the ISR, so I delegate that to a thread. Do I have the thread read the DMA buffer directly, and just pray that it does it fast enough that the ADC doesn't loop back around to that buffer until the thread is done?
Or, do I have the ISR copy the buffer into a queue, mitigating the memory corruption risk? Well that seems good, but how do I make the queue visible to both the ISR and the thread? The ISR takes no arguments, it's just an address the CPU jumps to when a thing happens. Thus, the queue has to be global, which means more unsafe blocks and more very un-idiomatic Rust.
side note: in my use case, it actually worked just fine with the thread reading straight from the DMA buffer, even with the risk of memory corruption. But you can imagine use cases where the risk would be more severe, like maybe decoding packets from a serial interface.
Rust is designed to make this type of issue impossible, but that assumes that you can correctly encode object lifetimes in the kernel in a way that allows the compiler to check them.
So I would say that any easy answer like “this would not compile” would just be a guess, because you would want to know more of the particulars in order to answer this question.
I know that this is kind of a non-answer, but if you want to write a kernel in Rust you have to figure out boundaries for where unsafe {} are. In a kernel, there are probably large chunks of unsafe {} and the Rust compiler prevents certain bugs outside unsafe {} assuming there aren’t bugs inside unsafe {} that would prevent the type checker from doing its job correctly.
I would say that Rust has a good story here. The simple form of this wouldn't compile. So you are generally presented two options:
1. Slap a reference count on it.
2. Use `unsafe` to promise the compiler that your code is right.
I would say that 1 is a pretty good habit to have. It may open you to memory leaks if you aren't careful but those are much less bad than a use-after-free or other memory management issues. And of course the fact that this was the route the patch took is a good sign. I think this is a pretty good default option.
Now if performance is a major issue you may consider going to 2, so it is impossible to say "Rust would have prevented this" because if it was originally written in Rust this may have been the route taken. But I think it is still very valuable to make that an explicit choice and obvious to reviewers and readers.
This is the answer I think. The correctness of your safe code is dependent on the diligence of the unsafe code except for the most simple cases. A kernel is going to have a pretty high unsafe to safe ratio compared to most usermode apps.
This really gets to the core of what I think Rust is about, you can add compiler checked constraints to your APIs that your C and C++ code can't. It's up to you to use them effectively. Rust's ability to keep your safe code safe is a measure of the language, but also your architecture. The buck has to stop somewhere for the language to prove safety, Rust lets you decide rather than the language itself.
I’m not an OS programmer and have been dabbling with OpenBSD’s code for fun. But the fact is that Rust kinda lacks flexibility. Most of the OS is dedicated to building a beautiful lie for programs to run happily, and that’s where C shine.
I shudder to think about the amount of work that it would take to convince the rust compiler that everything is all right. Most hardware interactions is “parse, don’t validate” which means you’ll be pinky-swearing to the compiler.
And for my cursory glances at the code, most structures are handled well, that it’s mostly logic bug (from bad data) instead of bad memory access (which can happen).
In practice you don't convince Rust that everything is right. You let it prove that most of the code is right and you promise it (via unsafe) that the rest is. Ideally these unsafe blocks would be carefully documented, reviewed and ideally enclosed in small modules that makes correctness easier to ascertain.
Rust is no panacea, but in my experience it is far easier to write memory safe code when the risky bits are discouraged and explicitly highlighted rather than every line of code being a possible risk. Humans are pretty bad at reviewing 100 lines of boring looking code (especially if this is one of dozens of patches this week) but much better (although by no means excellent at) reviewing 5 2-line unsafe blocks amongst 90 other lines of code.
Most data in the kernel are rather long lived or traversing too many layers. There are too many entry points (system calls, interrupts) into the kernel for guarantees to hold.
And OpenBSD development is rather slow. The tech mailing list average 300-400 mails a month.
Validation asserts what’s in the data type, while parsing just creates it. Especially in the context of C structures where you can just create it from a blob of bytes.
Not necessarily. Rust safety relies on OS primitives and the error here is in an OS primitive itself (kernel semaphores).
Yes Rust is one language that can be widely deployed in systems programming and potentially avoid classes of memory and ownership errors. No it doesn’t magically solve all the problems. Saying “Rust would fix this” in a hypothetical situation where Rust existed in 1995 or OpenBSD was rewritten from scratch, ok, well maybe. As of today only research kernels and a very small fraction of Linux systems have been written in Rust when we are talking about kernels.
People without systems and embedded programming experience need to sit down.
You might not be able to express the ownership in the way that can be checked statically, so quite possibly this would then be downgraded to a runtime error (that could be handled with a panic)—but not undefined behavior.
I often refrain from commenting about meta-issues on HN, but I'm particularly annoyed by the downvotes on this question of mine. What is this forum for, if not for this exchange between makers? I've noticed downvotes on questions are an oft occuring pattern. I think the comments on HN should house more than self-contained absolute statements.
OpenBSD wouldn't say anything like that. They're well aware of the 40+ year old codebase's limitations, but accept it because they're not so stupid as to "rewrite it in <other language>" which will bring a million bugs.
They've innovated again and again in the security space and aggressively bring in new security features like pf, OpenSSH, W^X enforcement, pledge(), arc4random(), ASLR, so many other things.
Unlike, say, NPM, which can't even replicate existing packaging systems like yum or apt, and has been plagued with security flaws despite being built entirely out of a memory-safe language. Quite an achievement.
> aggressively bring in new security features like pf, OpenSSH, W^X enforcement, pledge(), arc4random(), ASLR, so many other things.
I'd say OpenSSH is a great tool, arc4random was great and pledge is interesting although doesn't do much for code that wasn't compiled with it (and they are still really lacking in ways to lock down apps for a 'security focused' OS), the rest is just their implementation of stuff that already existed not something they innovated.
Most of their reputation comes from a time when linux distros and windows had every service enabled and exposed by default, it just developed it's own momentum the way many myths do.
It's difficult to say if a kernel written in rust would not have similar vulnerabilites, because it would be impossible to build a kernel without significant amounts of `unsafe`.
Oh it’s possible and people
do it in embedded all the time at great expense, but that safety isn’t assured by using a “safe” language, it comes from the requirements, documentation and verification process. OpenBSD’s kernel was developed with security in mind but not that level of safety.
Not really sure what you mean? You have to use `unsafe` in Rust to access arbitrary mutable pointers. How would you do DMA, or write a device driver, without `* mut T`
I’m referring to use of process (sometimes with a partial assist from qualified tools, of which Rust is NOT one) for safety assurance, not the language. As is done in safety and security critical embedded contexts. eg DO-178, Common Criteria, etc.
I know a lot about kernel programming. and the last thing as I would ever suggest as being core to kernel programming is that is a specialized discipline that uses different rules and shouldn't be accessible to neophytes. its just code. sometimes the restrictions are unfamiliar, but there is nothing magic going on here.
The OpenBSD project was started in 1995, with ancestry going back further than that. Should they have first invented Rust? Or at what point do you suppose the decades-old codebase should have been completely rewritten?
I think it's important to point out that OpenBSD is not more secure than others, it's just that it's not widely adopted so no one really does audit it.
Oh, hey, a local-user-to-root exploit on OpenBSD. Cool! Those are rare, but not unheard of, unless you're talking about Windows or Linux, where you don't hear much about this bug class, just since it's common-as-rainfall.
Anyway... Does this mean OpenBSD is suddenly less interesting? Nope, it's still pretty much the best-understandable general-purpose OS, ready for your RiiR fork. So, still go for that! Burn a universe or two worth of tokens! For the planet!
Does this mean OpenBSD is suddenly less secure? Nah... Its practical security level was never that much higher than that of its nominal competitors, despite Theo's best attempts, the best of which were replicated elsewhere and majority of it went ignored. The first class counts as "innovations", the rest as "experiments" which, no matter what anyone thinks, is not the same as "failed innovations."
But I digress. Now, go and donate to OpenSSH (because I bet you typed ssh today, didn't you, you rascal?), publish your OxidizedBSD fork, or whatever. Just don't link to that "is OpenBSD secure?" site, because, well, gauche, dude(tte)!
Seems to be found as a part of Patch The Planet [0] which is basically OpenAI giving model access and Trail of Bits using them to find vulnerabilities in OSS projects.
[0] https://openai.com/index/patch-the-planet/
Sidenote but... I read this on that link:
dnsmasq: Codex Security independently identified vulnerable patterns corresponding to four of the six dnsmasq CVEs later fixed in 2.92rel2: CVE-2026-4890 (opens in a new window), CVE-2026-4891 (opens in a new window), CVE-2026-4892 (opens in a new window), and CVE-2026-517
dnsmasq has had so many freaking security holes in 2025 and 2026 that atm I decided to just remove that thing from all my machines.
"dnsmasq has had so many freaking security holes in 2025 and 2026 that atm I decided to just remove that thing from all my machines."
Would be nice if OpenWRT would stop including it by default
What else is out there that fits openWRT's use case? BIND seems like it would be a bit "heavy"
For caching recursive dns, unbound?
I got the feeling that dnsmasq does more than just recursive dns though?
I think that is the "challenge" with dnsmasq. In addition to caching DNS it also does, dhcp, authoritative DNS, BOOTP and TFTP.
Unbound can do authoritative dns. It is a bit clunky so usually what you do is have NSD for the authoritative parts and unbound for the recursive parts. but unbound has local-zone: stub-zone: forward-zone: auth-zone: directives. I am not the most sophisticated dns admin but I am fairly sure that just unbound by itself can do almost any dns party trick you care to throw at it.
> Unbound can do authoritative dns
I don’t know whether they’re right, but https://www.openbsdhandbook.com/bind/ and https://www.openbsdhandbook.com/unbound/ disagree with that, saying you need the sublingual nsd for that.
I use NSD myself, but the man page sez an auth-zone directive could act like a self contained authoritive zone served from a file. the other way it can be used to to speed up the cache for the actual authoritive data.
https://man.openbsd.org/unbound.conf#AUTHORITY_ZONE_OPTIONS
"Authority zones are configured with auth-zone:, and each one must have a name. There can be multiple ones, by listing multiple auth-zone section clauses, each with a different name, pertaining to that part of the namespace. The authority zone with the name closest to the name looked up is used. Authority zones can be processed on two distinct, non-exclusive, configurable stages.
With for-downstream: yes (default), authority zones are processed after local-zones and before cache. When used in this manner, Unbound responds like an authority server with no further processing other than returning an answer from the zone contents. A notable example, in this case, is CNAME records which are returned verbatim to downstream clients without further resolution.
With for-upstream: yes (default), authority zones are processed after the cache lookup, just before going to the network to fetch information for recursion. When used in this manner they provide a local copy of an authority server that speeds up lookups for that data during resolving.
If both options are enabled (default), client queries for an authority zone are answered authoritatively from Unbound, while internal queries that require data from the authority zone consult the local zone data instead of going to the network.
An interesting configuration is for-downstream: no, for-upstream: yes that allows for hyperlocal behavior where both client and internal queries consult the local zone data while resolving. In this case, the aforementioned CNAME example will result in a thoroughly resolved answer.
Authority zones can be read from a zonefile. And can be kept updated via AXFR and IXFR. After update the zonefile is rewritten. The update mechanism uses the SOA timer values and performs SOA UDP queries to detect zone changes."
I wonder if people today remember BIND's history with security.
I would love to, but apparently its needed for libvirt.
It is required mainly for VMs that use virbr0 and NAT. Networking options like macvtap don't need it.
neat, i'm a big fan of trail of bits but apparently missed this announcement. here's their post: https://blog.trailofbits.com/2026/06/22/introducing-patch-th... and a summary of week 1: https://gist.github.com/patch-the-planet/69fd1aa925c8e73edea...
One bug found is a testament to the great diligence and culture around security of OpenBSD. Especially if you take into account the amount of resources they have been able to achieve this with.
+1
It is also a testament to solid engineering and attention to good security practices in general. These still work, also against fancy new AI attackers.
When sophisticated attacks become cheaper to run, maybe it will (finally) be cheaper to do more solid engineering instead of doing it quick and dirty and ending up in indefinite bug-squashing mode.
I suspect the easier option is to use AI to review your own code. The arms race between developers and attackers might even make some of the AI valuations come true.
While I agree, OpenBSD also doesn't fully implement features/functionality.
If your operating system only does 20% of what another operating system can do, it's easier for you to have 80% less bugs.
That's not a knock, it's a design philosophy of OpenBSD (which is to do the minimal needed, and no more, in the most simplistic way).
You're right, but of course OpenBSD does far more than 20%.
One thing I actually really like about OpenBSD is that things either work or they don't. There's no "Well it kind of works if you have this specific hardware set up and these programs running..." It just works 100% of the time, in 100% of the ways you expect, or it doesn't.
That does not match my experience with obsd. It is not so much minimalism as they are not afraid to reinvent the wheel. A obsd install is full of services, more than most linux installs I have seen.
For example you can imagine my disappointment when I discovered what a pain in the ass it is to get a pflow producer working on linux after doing the first one on openbsd.
I'd say it's true. They chose to not implement SMP until consumer CPUs surprised them by going multi thread.
And obsd has no Bluetooth, right? A pretty big subsystem to drop because security.
And as a counter example here you have openbsd "we are going to install a bgp daemon on every single device, because you never know when you may need one"
I am not complaining, I like the feeling that I could single handedly rebuild the internet using only what is found in an openbsd base install. But wow, considering the size there is a lot in there. They definitely punch above their weight.
It's not a counter example to give examples of what does exist.
And it's not like the BGP daemon is on by default. That'd be dumb. You could equally say that any Ubuntu system has equally many steps to turn on a BGP daemon, starting with `apt install frr`.
I sure hope openbsd's BGPd doesn't have any suid binaries. And if it doesn't, well that might just as well be a vacation photo instead of a binary for all the "code" it is.
I agree that they're punching above their weight, but I would also say that they are falling more and more behind. 25 years ago they were more at par in what use cases they can address, and its performance. But now it's almost retro computing.
And it's fine! If you really only need a bog standard webserver, or router/firewall, then that's the use case and it solves your problem. And solves the problem without baggage.
I wouldn't use it for storage, though, since running a non-checksumming filesystem nowadays is a bit of a joke. (let's not get into btrfs. I acknowledge its history, but checksumming is not backups, and backups address the historical btrfs problems while not addressing at all the checksumming)
But Bluetooth is basically a giant blast of security vulnerabilities. On the consumer side, yes, it's a big subsystem to drop, but on the server side, it's a little bit different!
I'm not an OpenBSD expert, but seems like you should be able to pass BT through USB and then do that in a subsystem or an isolated environment like a VM.
> you should be able to pass BT through USB
I use a Creative BT-W2 bluetooth usb dongle. Small and has a button on it for pairing. OpenBSD sees it as a normal audio device.
> But Bluetooth is basically a giant blast of security vulnerabilities
Yes, but this is exactly the point. And running OpenBSD is not a problem, until you run into a brick wall like this.
If you don't need it (and things like it), then that's all fine. As with everything, the last 10% takes 99% of the work, and code, and therefore contains about 99% of the security problems.
IIRC they were also very late to being able to run virtual machines, and even USB.
If you simply don't implement the things you don't need for a use case (e.g. a webserver) then that scales down to the fact that the compressor controller chip in your (dumb) fridge is not remotely exploitable too.
The Bluetooth spec is horrendous, and from what I read, the hardware is equally horrifying. Bluettoth is a wireless bus, not one class a device and an implementation would need to provide hooks to the other subsystems like wscons (keyboard and mouse), audio and network. OpenBSD does not have kernel modules, so it’s either in or not.
> The Bluetooth spec is horrendous
The Bluetooth Classic spec is indeed fairly awful, but the Bluetooth LE spec is not too bad. Plus, the entire specification is available free-of-charge, without even needing to register an account.
Bluetooth LE used to be limited to tiny accessories, but these days it supports nearly everything—I've completely disabled Bluetooth Classic on my (Linux) laptop because of how much of a disaster it is, but I'm still able to use my mouse and headphones over LE only.
> OpenBSD does not have kernel modules, so it’s either in or not.
But I'm assuming that not all kernel code is active at all times? Because it would seem odd to me if the amdgpu code was always active on something like a Raspberry Pi.
There’s a config[0] mechanism, both static and runtime that tells what gets enabled. In static mode, it tells what’s get compiled in the kernel, while you can disable any drivers (and save your config as a modified kernel) in a compiled one.
It mostly a drivers tree that describe how to probe for hadrware. Like mainbus -> pci -> xhci -> usb -> uaudio -> audio.
[0] https://man.openbsd.org/config.8
Depends on what you mean by active. The kernel has the code in the binary, but on boot it goes through device discovery and initialization, so it doesn't initialize or run drivers for things that aren't present.
There are also architecture specific builds, so the aarch64 build won't include driver code at all for devices that are specific to x86.
They mostly dropped it because nobody was around who could maintain it. Wasn't just about security.
My hobby horse is the lack of a “modern” filesystem on obsd.
Without journaling I really don’t agree with the oft repeated claims it makes a good “router”.
Any networking gear I’ve used is treated as an appliance and I don’t want an unfortunate power outage causing data loss.
I ran it diskless for years with read-only NFS mounts. Set up syslog and a pflog daemon to send logs elsewhere, and you don't need write access most of the time.
I believe that while the file system does not have journaling, that can be offset by applications. I.e. I think the SQLite Write Ahead Log would still protect you against data loss even if there's no journal in the file system, assuming you set various settings correctly. So I think it kinda depends on how the applications store data.
Yeah, if OpenBSD had ZFS it’d be perfect.
What's the use for a writable filesystem in network gear, that is detrimental if lost at power outage? Some sort of very important logging?
He does not know.
Out of curiosity, why put "router" in quotes?
OpenBSD's FFS can be told to be fully synchronous, making it about as robust as can be for not being journaled. If you lose power it will lose the specific data currently being written to disk. It won't lose other data, because it doesn't keep a bunch of it sitting around in a RAM cache while lying to the writing process about the I/O op already being completed. A journaled file system, too, will lose in-flight data that has yet to land on disk if the power is cut.
I've had my share of sudden power cuts hit OpenBSD during the 20+ years I've been using it, and I have yet to ever see its file system actually go corrupt.
A sincere question: what important data does your router frequently and busily need to persist? If you don't have a UPS for it, perhaps it isn't too important after all. Maybe we have different perspectives of what a router is and should be. I manage a router (with OpenBSD) and it can drop off the power grid at any moment without losing anything of importance. If your router is in fact a multi-functional server I can understand the notion. Consider making all of the file systems fully synchronous. It has worked great for me for two decades.
> OpenBSD's FFS can be told to be fully synchronous, making it about as robust as can be for not being journaled.
I am very interested, is there anything we can read to achieve that?
You can look at the mount command and the "sync" option: https://man.openbsd.org/mount
If you're really curious about it, Michael Lucas wrote a full book about the OpenBSD file system.
Man, thanks for this precious tip
If they can provide only 20% of the functionality and only 1% of the bugs, that's a compelling trade-off for many use-cases! (and a bit closer to the reality IMHO)
>That's not a knock, it's a design philosophy of OpenBSD (which is to do the minimal needed, and no more, in the most simplistic way)
you mean the most simple way. "simplistic" would mean they went too far.
https://en.wiktionary.org/wiki/simplistic
simplistic
1. Overly simple.
2. In a manner that simplifies a concept or issue so that its nuances and complexities are lost or important details are overlooked.
>That's not a knock, it's a design philosophy of OpenBSD (which is to do the minimal needed, and no more, in the most simplistic way)
you mean the most simple way. "simplistic" would mean they went too far.
Exactly, the entire AI industry has been trying to create an AI powered security arm race. I am not necessarily blaming them.
Hard to know how much has been thrown into this but I would bet a lot.
So far I have been very surprised we haven't been flooded by those type of announcements. If you look you will always find something and OpenBSD is the top price.
They are throwing tokens at codebases and finding mostly vulnerabilities in cases that have not been worth the limited time and effort of the chronically underfunded and understaffed professional groups. There’d be a lot more value in the companies giving the money they spend on their synthetic text extruders to the organizations doing quality security research work.
> they are ... finding ... vulnerabilities ... that have not been worth the time and effort ...
that's kinda the entire point
The point of the comment you are replying to is that it's also not worth the time and effort to use LLMs to find vulnerabilities, if "time and effort" can be measured with "money". If you factor in all the money spent on training, GPU data centers etc, it's not actually a financially efficient way to find bugs unless you profit from creating demand for LLMs. LLMs aren't cheaper than humans per unit work, yet. They're just massively deficit funded because capital thinks "AI" is going to reshape the world order, and wants in.
> it's not actually a financially efficient way ... unless you profit from creating demand for LLMs
well, they do? it's a win-win, you can't really criticise an AI lab for doing AI instead of straight up giving money to security researchers
> If you factor in all the money spent on training
why would I? it's not a cybersec-specific model
one bug is all it takes
In theory.
But real defenses are generally multi-layered. And in that context, a Swiss cheese slice with only one hole is still extremely valuable.
Well, that's where OpenBSD falls short, it lacks facilities to really enforce defense in depth - even NetBSD has some better features in this regard.
I don't think that's true? It runs most services as their own separate users, with pledge+unveil to limit what they can access even more. That's very much depth.
It is true. The do surface level protections, but have nothing to really lock down a system. What do they provide that can restrict an attacker who managed to compromise a remote service that wasn't using pledge or unveil? On other OS's, you can set things like append only, limit files being readable by particular processes, whitelist paths or executables from where the system may execute, etc etc etc.
Just popped up, about pledge+unveil - https://news.ycombinator.com/item?id=48851765
LPEs do need to be fixed, but for most people it's not a threat model they need to worry about.
this is a misconception
yes, most company settings don't run untrusted code, and OpenBSD is mostly used for servers not employee devices
but that doesn't mean LPEs aren't quite relevant, because they matter for pretty much everyone if combined with other vulnerabilities, like RCE, supply chain attack etc.
and while RCE are becoming less common, supply chain attacks have been increasingly more common
Yet it is not true that 1 bug is the same as 100 bugs.
There is no such thing as 0 bugs, and fewer is better than more.
OpenBSD's security stance being the stuff of legend, I'm curious how many vulns have been found over the last couple months while the big model companies are flaunting their ability to find exploits. It'd be super cool to see it remain tiny.
According to https://openai.com/index/patch-the-planet/
Linux: 24 LPEs, plus many additional vulnerabilities.
OpenBSD: 1 LPE.
FreeBSD: 7 LPEs, plus many additional vulnerabilities.
Not sure what that says, though. Perhaps the models are more likely to find Linux issues because of the training.
I wonder how many of the Linux the LPEs are related to drivers, which I understand there are more of..
Or Linux development is significantly more active.
This is an external audit. Why would Linux activity make a difference here? Are you theorizing that the churn causes bugs?
> Are you theorizing that the churn causes bugs?
Seems to be the case.
How many times do you see a bug investigation and it's determined when the bug was introduced?
Do you ever look at the diff that introduced it to understand what was going on in the project at the time? Often, it's in service to a new feature. Sometimes the original change is questionable when you consider you traded it for a severe bug.
When more code is written, more bugs are written.
Or, if the act of debugging is removing the bugs from software, then the act of programming is to put the bugs in the software.
Yes, "en-bugging" :)
I think "embuggening" has better cromulence.
Use it as a verb, like embiggening. :)
Not necessarily.
Depends on the quality of the code being written.
Quality*Quantity
Yes necessarily. Always. You need to invoke Nasa and fighter jets to find anything coming close, and they only manage to do any better by massive brute overkill in standards & procedures.
There's no plausible level of quality that reduces bugs to zero. More lines being written means more bugs being written, that's a statistical fact.
Linux is a much larger project receiving changes to tons of systems from lots of different sources. The combined behaviour of those things working together is massively harder to understand and test.
Copyfail being introduced by an optimization made to some random crypto module is a good example of this.
If you add 5 new pieces of hardware support in Linux vs 1 new in OpenBSD, I would expect more issues in Linux.
The Linux kernel is generally much larger than OpenBSD which is quite minimal.
But I do agree with you - not directly related to activity.
As another commenter said, number of bugs increases with lines of code changed.
And some code is absolutely unnecessary. Look at the yes command. GNU version is optimized to death for no reason at all[1].
OpenBSD's version is as simple as it gets[2].
[1]: https://github.com/coreutils/coreutils/blob/master/src/yes.c [2]: https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c
The others and I, working on GNU coreutils, frequently use 'yes' to generate a bunch of garbage input for testing programs. It is nice that it can do so quickly.
Just as another point of comparison, FreeBSD's version seems somewhere in-between. It also enables a Capsicum sandbox before processing any data, akin to what the OpenBSD version does with pledge.
[1] https://github.com/freebsd/freebsd-src/blob/main/usr.bin/yes...
Difference is that capsicum is after the fact and mostly about file descriptors. You need to open them in advance and _then_ call capsicum. But it does nothing about syscalls.
Capsicum is really nice if you plan ahead, but pledge/unveil is easy to drop into any existing code base.
Your blog isn't loading at the moment, so I'm not entirely sure what you mean here, but...
> capsicum is after the fact
After the fact in what sense? The program enters capability mode before touching any arguments or doing I/O. You have to set things up before enter capability mode because you can't escape out of it afterwards.
> it does nothing about syscalls
It does quite a lot about syscalls, in that it blocks or limits most of them. As the man page says: "Access to system calls in capability mode is restricted: some system calls requiring global namespace access are unavailable, while others are constrained."
In capability mode, you can use specific syscalls that operate on file descriptors, which limits the program to the specific capabilities it has been granted, e.g. pdkill(2) which is like kill(2) except you can only signal processes for which you have a process descriptor.
And yes, I went into that a while ago on my blog (https://blog.wollwage.com/2026/20260212-daily-source-reading...)
I completely agree with that
It is quite possible that Linux is the bigger target so it gets more focus. Vulnerabilities there are generally considered more valuable and notable. It would be very difficult to use these numbers to get a meaningful "more secure" stance as there are tons of variables.
From a quick search, Linux kernel is ~40 million loc, freebsd ~9 million, openbsd ~3 million. Number of bugs compared to lines of code leaves FreeBSD looking worse than Linux.
I assume those are lines of code in just the kernels.
As an FYI to everyone: The OpenBSD and FreeBSD teams both maintain entire distributions, similar to Linux + Debian or Linux + Redhat. The OpenBSD team also owns a number of other projects - everything from OpenSSH to PF, OpenBGPD, OpenNTPD, OpenSMTPD, OpenIKED, LibreSSL, pledge and unveil, their own set of perl patches, etc.
I'd say that less lines of code seems to correlate with less bugs in absolute numbers, which works out as more secure for those who don't need the extra code.
Linux also has a ton of extra functionality so I think you’d also have to do some adjustment for “as a user would I be at risk?” versus “can I be a user because it supports my needs?” Some of that would be unfavorable for many users (e.g. a Linux user who is exposed due to a network protocol or file system they’ll never use) but that’s certainly not true of every feature.
That cuts both ways, though. If the functionality is present by default but I'm not using it, that's just extra vulnerability surface. (Of course, if I do want that feature, then its absence is kinda a problem)
Hence the second sentence.
Linux also has a ton of bloat. Configuring your own kernel has become an exercise in frustration because documentation is worse "There is no help for this kernel option" and a lot of things are enabled "by default".
Yes, that’s why I wrote the second sentence. However, it’s quite an exaggeration that it’s super hard to configure a kernel - distributions can do that for you (e.g. Amazon Linux disabled a bunch of drivers for hardware you’ll never have in EC2), modules can easily be disabled (common remediation for those IPsec accelerators earlier this year), and it’s not that hard to build your own kernels and distribute them on most popular distributions.
If this is just counting the kernel, than Linux is probably a bigger target both i terms of current code size and the amount of churn in the codebase as things change over time. Some of the LPEs might (I've not checked) be in modules that are not commonly loaded, which mitigates their overall significance somewhat.
In the less likely even that this is counting what laymen would call Linux or BSD, i.e. both the kernel and common libraries & tools, then Linux definitely has a wider attack surface. Though some of that surface is shared as some userland parts are common to both.
As with your assessment, I'd agree that these flat numbers without looking for further context don't really give enough for a one-is-more-or-less-secure statement.
Linux LPEs have never been in short supply, even before the AI age.
The commit logs over the last few months have highlighted when an issue was found by a program. They usually name the submitter and the tool.
I think of it more as their attention to quality in their code:
Given the 'quality' of most code, especially under commercial pressure, it's no surprise that much more effective tools will find many more vulnerabilities. Did OpenBSDs quality approach work in this respect?
A local escalation in BSD is still apparently worth a front page post here, so that seems pretty good.
I wonder why we don’t see more about local escalations in Windows. Of course, being closed source is a little bit of a barrier, but these tools can read assembly pretty well, right?
I’ve heard a couple people say that Microsoft has patched a record number of bugs internally this year so it might be the case that it’s simply more opaque because it’s initiated internally and doesn’t involve a public Git repo or a third-party researcher.
You don't hear about them because you're probably not paying attention to where all the Windows admins hang out. Nearly every single patch tuesday over the past couple of years has been an emergency race to get things patched as soon as you can, for both local and remote exploits.
> OpenBSD's security stance being the stuff of legend,
More so their marketing.
What does openbsd marketing look like?
Mostly Comic Sans.
only on some operating systems.
Pretty sure you're familiar with their claims.
I'm not actually, because I'm damn sure I've never seen a piece of openbsd marketing in my life. All i know is that they're oriented around security and are notorious about rejecting patches.
> I'm damn sure I've never seen a piece of openbsd marketing in my life
Kind of weird for you to defend a product if you've never even been to their website.
Yes, you know that because of their marketing.
Do you have an example of this?
The first line of text on their homepage?
But I don't see anything wrong with OpenBSD saying they focus on security when it's well documented that they do, in fact, focus heavily on security.
> Only two remote holes in the default install, in a heck of a long time!
https://www.openbsd.org/
https://en.wikipedia.org/wiki/OpenBSD#Security_record
LPE (to root) is serious, but it's not a remote hole.
Is this functionality accessible from sandboxed processes? That would make a remote hole much more dangerous when one is found, anyway. The CVE seems to concern SysV semaphores and the pledge(2) man page doesn't seem to mention those.
No.
https://github.com/openbsd/src/blob/d5b0ed23b6fe61f0278c37a4...
Perhaps relevant, Students from the University of Southern Denmark released a paper earlier this month, which once again noted the fact that over ~90% of the OpenBSD base system uses pledge(2). Almost certainly all of the network speaking daemons in base do.
https://arxiv.org/abs/2607.03056
from the link:
sys/kern/sysv_sem.c in OpenBSD through 7.9 has a use-after-free allowing local privilege escalation to root. This is a context switch use-after-free after tsleep in sys_semget().
Can anyone find the mailing list thread on this topic (or does it not exist because @security are private mailing list)?
I did find another use-after-free bug from a couple months ago on the mailing list:
https://marc.info/?t=177581065500002&r=1&w=2
If this is a local privilege escalation to root, why can't I find anything on https://www.openbsd.org/security.html ?
Best guess, from the commit message alone[0]: It was fixed as a bug, at the time they didn't have evidence it could lead to LPE
The AI security tool then, retroactively discovered that it could have been used for LPE.
Again, just my guess I could be wrong.
[0] https://github.com/openbsd/src/commit/1957873d2063db11dab780...
OpenBSD has a reputation for being... selective about what they admit is a security-relevant bug.
They appreciate technical correctness and they do not exaggerate. Most 'security researchers' are not technically correct and they exaggerate a lot (seeking fame and all).
Dismissing their claims is not being selective, it's just the right thing to do.
Exactly! As an open source developer who has a notable-enough-for-Wikipedia 25-year-old project out there (MaraDNS), let me tell you, a lot of “security bugs” found by AI-assisted researchers are anything but security bugs. Just some examples of stuff which ended up in my inbox recently:
- A security “bug” where someone who sends hundreds of millions of spoofed DNS queries could possibly have one come through. This is a problem with the DNS protocol, and it’s a problem with broken servers which drop DNS packets under some circumstances. It’s a long known issue where, in reality, the exploit isn’t incredibly practical (to say the least).
- A security “bug” where someone saw `strcat` in my code and assumed it was automatically a big huge buffer overflow exploit. No, it wasn’t: I did bounds checking in all cases, except one case where the program in question hasn’t been able to even compile since 2022 (and is a side utility which isn’t needed in any way, shape, or form to run MaraDNS).
- A bunch of security “bugs” which were cases where my recursive resolver took a few seconds to fully drop resources used to solve a DNS query if it got various kinds of weird packets. This researcher claimed one bug was a remote packet of death, so I spent an entire afternoon writing a test case creating the packet in question. Nope, no packet of death.
- Finally, one researcher did find a security bug in the TCP code for the recurisve resolver, where an authorized client could disable the TCP server (without affecting the UDP server). Keep in mind that the code doesn’t enable TCP by default, a user would have to go out of their way to enable DNS-over-TCP, and it’s not a “packet of death” because the IP sending the bad TCP packets has to be one already authorized to perform recursive queries.
With the DNS-over-TCP bug, I patched the code and made a new MaraDNS release. With the overflow in the code which hasn’t compiled since 2022, I fixed the bug, patched the code to compile again, then next removed the code completely from MaraDNS (putting it in “MaraDNS-attic”).
As an aside, djbdns users may have observed that, because of the C23 changes, djbdns doesn’t even compile anymore, and I am not aware of anyone besides myself caring enough to post patches. In my own distribution of djbdns, I have instructed people to set CC to "c99 -D_DEFAULT_SOURCE" so that the code can compile again.
The fact that most security researches tend to bullshit to pump up their numbers doesn't mean that OpenBSD isn't selective.
The main claim from OpenBSD is "Only two remote holes in the default install since forever".
It is technically true. But it's also selective because they deliberately disable every service by default and don't install any software beyond core.
Once the OS is configured to be useful, we're far from the default install and they would (and have!) refuse to update their motto when confronted with RCEs in those parts.
Which is fair enough! You gotta draw the line somewhere. But that's still being very selective.
> they deliberately disable every service by default and don't install any software beyond core.
Do you prefer that or everything (or most/many services) being enabled by default? It's a good practice and, for me, very practical - I don't need to find everything I'm not using and disable it.
Nobody is saying that their minimal default install is itself problematic.
But trumpeting your default install's safety record doesn't actually say much when the default install doesn't actually do anything. As soon as you add a package or a port you're beyond "default install" territory and their vaunted security reputation's coverage.
I think we agree except one point: IMHO the security of their default install is worth trumpeting: disabling by default is not a technical wonder, but it's good security that others don't do.
Would Rust have made this issue impossible by construction? I know Linus has spoken about Rust's promises about memory safety not being equivalently applicable in the kernel domain, so I would be curious to hear any kernel developer's perspectives.
I'm not a kernel developer but I am an embedded firmware engineer.
To be clear: I like Rust. It's great, I use it a lot. But, Rust's memory safety stuff can't really save you from the screwiness of ISRs. Here's a long-winded example:
ST has a nifty double-buffer DMA mode for their ADCs, so you can give the ADC two different buffers, it'll fill one, fire an IRQ, you catch the IRQ and handle the data, meanwhile, it's filling the other buffer, and the IRQ fires again, you handle the data in the other buffer, rinse, repeat.
This allows the ADC to run continuously, monotonically and at very high sample rates, without monopolizing CPU. It's really a terrific design. I used it for a DIY telephony project once to run continuous FFTs on several ADC channels at once.
This is all fun, but the architecture introduces synchronization issues that aren't immediately solvable within Rust's data model.
Okay, so I can't run the FFT from within the ISR, so I delegate that to a thread. Do I have the thread read the DMA buffer directly, and just pray that it does it fast enough that the ADC doesn't loop back around to that buffer until the thread is done?
Or, do I have the ISR copy the buffer into a queue, mitigating the memory corruption risk? Well that seems good, but how do I make the queue visible to both the ISR and the thread? The ISR takes no arguments, it's just an address the CPU jumps to when a thing happens. Thus, the queue has to be global, which means more unsafe blocks and more very un-idiomatic Rust.
side note: in my use case, it actually worked just fine with the thread reading straight from the DMA buffer, even with the risk of memory corruption. But you can imagine use cases where the risk would be more severe, like maybe decoding packets from a serial interface.
Rust is designed to make this type of issue impossible, but that assumes that you can correctly encode object lifetimes in the kernel in a way that allows the compiler to check them.
So I would say that any easy answer like “this would not compile” would just be a guess, because you would want to know more of the particulars in order to answer this question.
I know that this is kind of a non-answer, but if you want to write a kernel in Rust you have to figure out boundaries for where unsafe {} are. In a kernel, there are probably large chunks of unsafe {} and the Rust compiler prevents certain bugs outside unsafe {} assuming there aren’t bugs inside unsafe {} that would prevent the type checker from doing its job correctly.
I would say that Rust has a good story here. The simple form of this wouldn't compile. So you are generally presented two options:
1. Slap a reference count on it.
2. Use `unsafe` to promise the compiler that your code is right.
I would say that 1 is a pretty good habit to have. It may open you to memory leaks if you aren't careful but those are much less bad than a use-after-free or other memory management issues. And of course the fact that this was the route the patch took is a good sign. I think this is a pretty good default option.
Now if performance is a major issue you may consider going to 2, so it is impossible to say "Rust would have prevented this" because if it was originally written in Rust this may have been the route taken. But I think it is still very valuable to make that an explicit choice and obvious to reviewers and readers.
This is the answer I think. The correctness of your safe code is dependent on the diligence of the unsafe code except for the most simple cases. A kernel is going to have a pretty high unsafe to safe ratio compared to most usermode apps.
This really gets to the core of what I think Rust is about, you can add compiler checked constraints to your APIs that your C and C++ code can't. It's up to you to use them effectively. Rust's ability to keep your safe code safe is a measure of the language, but also your architecture. The buck has to stop somewhere for the language to prove safety, Rust lets you decide rather than the language itself.
I’m not an OS programmer and have been dabbling with OpenBSD’s code for fun. But the fact is that Rust kinda lacks flexibility. Most of the OS is dedicated to building a beautiful lie for programs to run happily, and that’s where C shine.
I shudder to think about the amount of work that it would take to convince the rust compiler that everything is all right. Most hardware interactions is “parse, don’t validate” which means you’ll be pinky-swearing to the compiler.
And for my cursory glances at the code, most structures are handled well, that it’s mostly logic bug (from bad data) instead of bad memory access (which can happen).
In practice you don't convince Rust that everything is right. You let it prove that most of the code is right and you promise it (via unsafe) that the rest is. Ideally these unsafe blocks would be carefully documented, reviewed and ideally enclosed in small modules that makes correctness easier to ascertain.
Rust is no panacea, but in my experience it is far easier to write memory safe code when the risky bits are discouraged and explicitly highlighted rather than every line of code being a possible risk. Humans are pretty bad at reviewing 100 lines of boring looking code (especially if this is one of dozens of patches this week) but much better (although by no means excellent at) reviewing 5 2-line unsafe blocks amongst 90 other lines of code.
Most data in the kernel are rather long lived or traversing too many layers. There are too many entry points (system calls, interrupts) into the kernel for guarantees to hold.
And OpenBSD development is rather slow. The tech mailing list average 300-400 mails a month.
I thought that parsing implied validation. Is this not the case?
Validation asserts what’s in the data type, while parsing just creates it. Especially in the context of C structures where you can just create it from a blob of bytes.
Ah, I suppose in my mind parsing precludes the idea of invalid data.
The Rust ownership model prevents use after free. This type of a bug would not compile.
Not necessarily. Rust safety relies on OS primitives and the error here is in an OS primitive itself (kernel semaphores).
Yes Rust is one language that can be widely deployed in systems programming and potentially avoid classes of memory and ownership errors. No it doesn’t magically solve all the problems. Saying “Rust would fix this” in a hypothetical situation where Rust existed in 1995 or OpenBSD was rewritten from scratch, ok, well maybe. As of today only research kernels and a very small fraction of Linux systems have been written in Rust when we are talking about kernels.
People without systems and embedded programming experience need to sit down.
I don't think this is about core kernel semaphores but rather the SysV semaphore system calls?
You might not be able to express the ownership in the way that can be checked statically, so quite possibly this would then be downgraded to a runtime error (that could be handled with a panic)—but not undefined behavior.
I often refrain from commenting about meta-issues on HN, but I'm particularly annoyed by the downvotes on this question of mine. What is this forum for, if not for this exchange between makers? I've noticed downvotes on questions are an oft occuring pattern. I think the comments on HN should house more than self-contained absolute statements.
Blasphemy
and yet...
[dead]
[dead]
[flagged]
OpenBSD wouldn't say anything like that. They're well aware of the 40+ year old codebase's limitations, but accept it because they're not so stupid as to "rewrite it in <other language>" which will bring a million bugs.
They've innovated again and again in the security space and aggressively bring in new security features like pf, OpenSSH, W^X enforcement, pledge(), arc4random(), ASLR, so many other things.
Unlike, say, NPM, which can't even replicate existing packaging systems like yum or apt, and has been plagued with security flaws despite being built entirely out of a memory-safe language. Quite an achievement.
> aggressively bring in new security features like pf, OpenSSH, W^X enforcement, pledge(), arc4random(), ASLR, so many other things.
I'd say OpenSSH is a great tool, arc4random was great and pledge is interesting although doesn't do much for code that wasn't compiled with it (and they are still really lacking in ways to lock down apps for a 'security focused' OS), the rest is just their implementation of stuff that already existed not something they innovated.
Most of their reputation comes from a time when linux distros and windows had every service enabled and exposed by default, it just developed it's own momentum the way many myths do.
It's difficult to say if a kernel written in rust would not have similar vulnerabilites, because it would be impossible to build a kernel without significant amounts of `unsafe`.
Oh it’s possible and people do it in embedded all the time at great expense, but that safety isn’t assured by using a “safe” language, it comes from the requirements, documentation and verification process. OpenBSD’s kernel was developed with security in mind but not that level of safety.
Not really sure what you mean? You have to use `unsafe` in Rust to access arbitrary mutable pointers. How would you do DMA, or write a device driver, without `* mut T`
I’m referring to use of process (sometimes with a partial assist from qualified tools, of which Rust is NOT one) for safety assurance, not the language. As is done in safety and security critical embedded contexts. eg DO-178, Common Criteria, etc.
Tell us you know nothing about kernel programming and trust stacks while you are at it.
I know a lot about kernel programming. and the last thing as I would ever suggest as being core to kernel programming is that is a specialized discipline that uses different rules and shouldn't be accessible to neophytes. its just code. sometimes the restrictions are unfamiliar, but there is nothing magic going on here.
If you knew a lot you would stop digging.
The OpenBSD project was started in 1995, with ancestry going back further than that. Should they have first invented Rust? Or at what point do you suppose the decades-old codebase should have been completely rewritten?
It's not too late to start now, similar to how Linux did a few years back.
Rumours of Linux being rewritten in Rust are greatly exaggerated.
No one is claiming that, they are at least setting a foundation for that to be possible though.
where poc?
no poc = hyped false marketing from openai, lying about it is lpe. same with claude bug 27y.
Anybody know why the compiler didn't pick this up?
Ah, it was too good to be true, BSD too is becoming rusty.. ahh, what's left?
I think it's important to point out that OpenBSD is not more secure than others, it's just that it's not widely adopted so no one really does audit it.
> no one really does audit it
Isn't this article about an AI that just audited it?
> not more secure than others
Didnt the audit only found one bug, much less than other kernels from the same audit?
Oh, hey, a local-user-to-root exploit on OpenBSD. Cool! Those are rare, but not unheard of, unless you're talking about Windows or Linux, where you don't hear much about this bug class, just since it's common-as-rainfall.
Anyway... Does this mean OpenBSD is suddenly less interesting? Nope, it's still pretty much the best-understandable general-purpose OS, ready for your RiiR fork. So, still go for that! Burn a universe or two worth of tokens! For the planet!
Does this mean OpenBSD is suddenly less secure? Nah... Its practical security level was never that much higher than that of its nominal competitors, despite Theo's best attempts, the best of which were replicated elsewhere and majority of it went ignored. The first class counts as "innovations", the rest as "experiments" which, no matter what anyone thinks, is not the same as "failed innovations."
But I digress. Now, go and donate to OpenSSH (because I bet you typed ssh today, didn't you, you rascal?), publish your OxidizedBSD fork, or whatever. Just don't link to that "is OpenBSD secure?" site, because, well, gauche, dude(tte)!
Now I've seen it all.
I've pondered it for an entire day, and I still have no idea what that means...