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.
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.
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?
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.
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.
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.
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.
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’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).
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.
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`.
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?
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().
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)!
[0] https://openai.com/index/patch-the-planet/
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
https://www.openbsd.org/
https://en.wikipedia.org/wiki/OpenBSD#Security_record
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.
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.
But I do agree with you - not directly related to activity.
More so their marketing.
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?
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...
Dismissing their claims is not being selective, it's just the right thing to do.
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.
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.
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 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).
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.
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().
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)!