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.
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.
show comments
uticus
> Only two remote holes in the default install, in a heck of a long time!
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.
Anybody know why the compiler didn't pick this up?
WhereIsTheTruth
Ah, it was too good to be true, BSD too is becoming rusty.. ahh, what's left?
gjvc
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().
iberator
Blasphemy
show comments
poly2it
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.
show comments
bitwize
"'Nothing could have prevented this from happening,' say users of only language where this happens" comes to bite OpenBSD.
show comments
rs_rs_rs_rs_rs
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.
IveSeenItAll
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/
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.
> 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
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.
If this is a local privilege escalation to root, why can't I find anything on https://www.openbsd.org/security.html ?
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
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?
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().
Blasphemy
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.
"'Nothing could have prevented this from happening,' say users of only language where this happens" comes to bite OpenBSD.
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)!