OpenBSD has a use-after-free allowing local privilege escalation to root

nvd.nist.gov137 pointsby linggen65 comments

Discussion summary

OpenBSD has a use-after-free vulnerability that allows local privilege escalation. Discussions include the security of OpenBSD, the potential of Rust in kernel development, and the challenges of rewriting legacy code.

What the discussion says

OpenBSD's codebase is old but accepted as a trade-off for stability.
Some believe Rust could prevent such vulnerabilities, but it's not guaranteed.
OpenBSD's security is not inherently better, just less scrutinized.
Rewriting legacy code in new languages like Rust is complex and debated.

“OpenBSD has a use-after-free vulnerability allowing privilege escalation.”
— Anonymous

“Would Rust have made this issue impossible by construction?”
— poly2it

Comments

Hacker News

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)!

by IveSeenItAll

Now I've seen it all.

by sgt

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.

by rs_rs_rs_rs_rs

"'Nothing could have prevented this from happening,' say users of only language where this happens" comes to bite OpenBSD.

by bitwize

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?

by applfanboysbgon

Tell us you know nothing about kernel programming and trust stacks while you are at it.

by anoneng

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`.

by efficax

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.

by amiga386

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.

by poly2it

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).

by skydhash

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.

by poly2it

The Rust ownership model prevents use after free. This type of a bug would not compile.

by rwaksmunski

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.

by klodolph

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.

by ryukoposting

Blasphemy

by iberator

and yet...

by znpy

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().

by gjvc

Ah, it was too good to be true, BSD too is becoming rusty.. ahh, what's left?

by WhereIsTheTruth

Anybody know why the compiler didn't pick this up?

by sys_64738

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

by tiffanyh

If this is a local privilege escalation to root, why can't I find anything on https://www.openbsd.org/security.html ?

by jsiepkes

OpenBSD has a reputation for being... selective about what they admit is a security-relevant bug.

by stackghost

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...

by justthehuman

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.

by Arubis

> OpenBSD's security stance being the stuff of legend,

More so their marketing.

by JCattheATM

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?

by mmooss

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.

by ectospheno

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.

by wahern

> 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

by uticus

LPE (to root) is serious, but it's not a remote hole.

by anonym29

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Hacker News
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)!
by IveSeenItAll
Now I've seen it all.
by sgt
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.
by rs_rs_rs_rs_rs
"'Nothing could have prevented this from happening,' say users of only language where this happens" comes to bite OpenBSD.
by bitwize
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?
by applfanboysbgon
Tell us you know nothing about kernel programming and trust stacks while you are at it.
by anoneng
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`.
by efficax
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.
by amiga386
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.
by poly2it
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).
by skydhash
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.
by poly2it
The Rust ownership model prevents use after free. This type of a bug would not compile.
by rwaksmunski
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.
by klodolph
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.
by ryukoposting
Blasphemy
by iberator
and yet...
by znpy
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().
by gjvc
Ah, it was too good to be true, BSD too is becoming rusty.. ahh, what's left?
by WhereIsTheTruth
Anybody know why the compiler didn't pick this up?
by sys_64738
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
by tiffanyh
If this is a local privilege escalation to root, why can't I find anything on https://www.openbsd.org/security.html ?
by jsiepkes
OpenBSD has a reputation for being... selective about what they admit is a security-relevant bug.
by stackghost
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...
by justthehuman
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.
by Arubis
> OpenBSD's security stance being the stuff of legend,
More so their marketing.
by JCattheATM
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?
by mmooss
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.
by ectospheno
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.
by wahern
> 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
by uticus
LPE (to root) is serious, but it's not a remote hole.
by anonym29