?? it seems pretty well documented code? sure a bunch refers to internals of what the exploit is touching, that might be tricky to follow but you cant expect comments to go and explain all touched subsystems etc. that documentation is in the software being targeted.... openBSD has really good docs..
Do you really consider "The SHM attachment-counter wrap and detach race publish NEW with a freed UAO." a valid sentence? It has hints of what it does, but is otherwise nearly undecipherable.
Later on, there's "Three additional children compensate for banking 127 rather than 128 records per vmspace and still cross the signed 16-bit boundary." which at first glance appears to be something about bank-switching, but isn't.
It’s remarkable that a bug survived 37 years in one of the most heavily audited codebases, which shows how hard some kernel bugs are to catch by review alone. Do you think fuzzing or static analysis could realistically have found this class of bug, or did it need a human thinking about the exploit primitive?
Every blog post on this site is AI generated and covers bugs and exploits that were uncovered also by AI
So, sort of like fuzzing. There's a scary amount of exploitable stuff like this sitting in every BSD and Linux system out there, including every embedded system running old kernels in routers, cars, plcs, on and on
They clearly have some AI-generated write-ups, which I guess is fine for utilitarian stuff like that, but the post in question appears to be entirely human.
Fuzzing doesn't tend to catch overflow cases since operations aren't repeated enough times. I wonder if fuzz engines could add a "counter detection" pass that reruns inputs that are seen to increment values. Maybe that's already been tried by someone.
The idea of "OpenBSD is super duper secure" is mostly a fiction. Their prime claim to fame, "only two remote holes in the default install in a squillion years", is pretty meaningless because the default install doesn't really do anything, so as soon as you install packages to make the system useful you're beyond their security claims.
Classified workstations in National Security contexts? They run Windows.
Red network routers? They're Cisco, Juniper, PAN, etc. It's all COTS stuff. OpenBSD is mostly a LARP.
> is pretty meaningless because the default install doesn't really do anything
Which is a good thing. An important thing. The reason you're stuck in a perpetual update cycle for most Linux distros and for Windows is that they ship with an insane number of things that most users have no need for. Yeah, every laptop definitely needs NetBIOS and iSCSI and UPnP turned on by default.
It's true that everything you add on top of the OpenBSD baseline increases your attack surface, but it's a saner approach than shipping with a gigantic attack surface and then forcing you to know about and disable the things you don't need.
> Classified workstations in National Security contexts? They run Windows.
Which is almost certainly a combination of the complexities of govt IT procurement, the needs of non-technical users who may only be familiar with Windows & MS Office, and the enterprise management features of Windows that aren't as good in most other OSes.
I'll never understand this point. It's not as though that slogan is the entirety of OpenBSDs security posture. It's just a damn slogan, but OpenBSD naysayers will never stop talking about it.
And no, OpenBSD is not the most secure OS out there, and very few serious people claim it is. What OpenBSD is, is the most secure option if you want a simple, no bullshit, well documented unix that can still run on obscure legacy hardware using a potato as your RAM. As such, when you actually compare it to other options in that space, I would say it is the most secure. They care about security very deeply, but they do it within that context. So yes, they still use C, because they need to compile on a bunch of dead platforms. And OpenBSD is never gonna be something like Qubes because Qubes needs things like VT-D and a boatload of memory/cores, it's never gonna be GrapheneOS because they can't rely on having MTE, TPM, etc. And that's fine.
They also deserve a lot of credit for contributions to the wider ecosystem as well. Just to give one example, making sure the OS can provide high quality entropy in all contexts with arc4random, which eventually percolated to FreeBSD, Linux, and even MacOS.
But sure, keep talking about the two holes if you want.
The base install includes a firewall, http server, load-balancer/proxy, ldap server, caching DNS resolver, ssh server, nfs server, dhcp server, smtp server, bgp routing daemon, virtual machine subsystem, and a lot of other stuff I'm probably forgetting.
OpenBSD was used under NDA's in some really sensitive corpos with Gnome2 setups and some RDP/Citrix clients and even Perl?+GTK2 wireless graphical assisatnt.
If OpenBSD had a stable GeFS setup as a filesystem -still WIP- (and toad/hotplugd for external FS' mounting) it could get customers in no time, because today except for CUDA the rest can virtually work 100% the same as any Linux distro.
I think there's this cultural bias about the 'boy genius open source coder' that of course isn't true at all. Open source code is at the same quality as corporate written closed source code, in general. There have been studies on this and open vs closed source code isn't very different in terms of defects and exploits.
The problem is the people most willing to buy into this cargo cult mentality are techies, so tech forums are the last place to really have this conversation based on facts. Hence why your comment is barely visible here due to its low karma.
Not that remarkable. Nobody in history has been able to write correct C code, and that includes OpenBSD developers.
I pointed an AI at the smallest two tools in OpenBSD I could think of, cat and find, and found multiple bugs. One of which was a buffer overflow (albeit unlikely to be exploitable). IIRC these bugs had existed since at least the NetBSD/OpenBSD split.
I looked for bugs in Linux coreutils on a Russian Elbrus PC.
It has a very interesting protected mode of operation where every memory pointer is tagged.
So, I just ran tests and quickly found a number of memory-related bugs.
I’ve submitted some patches, but they were never accepted. These tools’ maintainers seemed very inertial to me. So maybe this is why many (low importance, I assume) issues persists there for a long time.
I feel like this is the elephant in the room. People keep acting surprised these large codebases are full of bugs and exploits. C isn't a safe language and moving to safe languages is going to be the only lasting solution.
Heavily audited might be a stretch. Who did the audit and what knew to look for is key. I wonder if they are using agentic tools to help improve the frequency and quality of their audits. Volunteer time is precious and getting robots to help might be useful, but I can also see it taking more of that same volunteer time to get good results from the robots. Either way, its their project and and they'll do as they deem fit, which is totally fine.
Interestingly, looks like this was accidentally fixed in NetBSD during a rewrite of that code in August of 1999.
NetBsd os the King. Most portable operating system (not just kernel) on the Planet.
All back to 1978 VAX/780 - still working from single base sources as x86 or ARM
OpenBSD had VAX support until a few years ago.
The difference is OpenBSD requires that the whole build runs natively on real hardware that they own. Probably not many vaxen on the pairie anymore.
If you're going to cross-compile and run it in an emulator, you may as well boot up OpenBSD 3.0.
Props for the OpenBSD Release -style graphics. Looking forward to the theme song.
Poor OpenBSD guys. Now they have to acknowledge THREE exploits (in total) on their homepage.
> Only two remote holes in the default install, in a heck of a long time!
This isn't remote (and I don't think the only local in recent times) - so, no - they won't have to update.
Map 127 SysV shared memory segments, unmap them via munmap(), and fork 259 processes to wrap the shared memory attach count to -32,643.
LOL. The actual exploit code at https://news.ycombinator.com/item?id=24456247
?? it seems pretty well documented code? sure a bunch refers to internals of what the exploit is touching, that might be tricky to follow but you cant expect comments to go and explain all touched subsystems etc. that documentation is in the software being targeted.... openBSD has really good docs..
Do you really consider "The SHM attachment-counter wrap and detach race publish NEW with a freed UAO." a valid sentence? It has hints of what it does, but is otherwise nearly undecipherable.
Later on, there's "Three additional children compensate for banking 127 rather than 128 records per vmspace and still cross the signed 16-bit boundary." which at first glance appears to be something about bank-switching, but isn't.
I fond some llms gemerate awful code comments. Claude is the worst offender I use.
It’s remarkable that a bug survived 37 years in one of the most heavily audited codebases, which shows how hard some kernel bugs are to catch by review alone. Do you think fuzzing or static analysis could realistically have found this class of bug, or did it need a human thinking about the exploit primitive?
Every blog post on this site is AI generated and covers bugs and exploits that were uncovered also by AI
So, sort of like fuzzing. There's a scary amount of exploitable stuff like this sitting in every BSD and Linux system out there, including every embedded system running old kernels in routers, cars, plcs, on and on
They clearly have some AI-generated write-ups, which I guess is fine for utilitarian stuff like that, but the post in question appears to be entirely human.
6 replies →
It's not as heavily audited as you think. They have like a dozen active developers.
How many developers do you need (and trust) to review patches?
They only audit the kernel and base userland. Ports are subject to far less scrutiny.
2 replies →
Fuzzing doesn't tend to catch overflow cases since operations aren't repeated enough times. I wonder if fuzz engines could add a "counter detection" pass that reruns inputs that are seen to increment values. Maybe that's already been tried by someone.
>in one of the most heavily audited codebases
The idea of "OpenBSD is super duper secure" is mostly a fiction. Their prime claim to fame, "only two remote holes in the default install in a squillion years", is pretty meaningless because the default install doesn't really do anything, so as soon as you install packages to make the system useful you're beyond their security claims.
Classified workstations in National Security contexts? They run Windows.
Red network routers? They're Cisco, Juniper, PAN, etc. It's all COTS stuff. OpenBSD is mostly a LARP.
> is pretty meaningless because the default install doesn't really do anything
Which is a good thing. An important thing. The reason you're stuck in a perpetual update cycle for most Linux distros and for Windows is that they ship with an insane number of things that most users have no need for. Yeah, every laptop definitely needs NetBIOS and iSCSI and UPnP turned on by default.
It's true that everything you add on top of the OpenBSD baseline increases your attack surface, but it's a saner approach than shipping with a gigantic attack surface and then forcing you to know about and disable the things you don't need.
> Classified workstations in National Security contexts? They run Windows.
Which is almost certainly a combination of the complexities of govt IT procurement, the needs of non-technical users who may only be familiar with Windows & MS Office, and the enterprise management features of Windows that aren't as good in most other OSes.
7 replies →
I'll never understand this point. It's not as though that slogan is the entirety of OpenBSDs security posture. It's just a damn slogan, but OpenBSD naysayers will never stop talking about it.
And no, OpenBSD is not the most secure OS out there, and very few serious people claim it is. What OpenBSD is, is the most secure option if you want a simple, no bullshit, well documented unix that can still run on obscure legacy hardware using a potato as your RAM. As such, when you actually compare it to other options in that space, I would say it is the most secure. They care about security very deeply, but they do it within that context. So yes, they still use C, because they need to compile on a bunch of dead platforms. And OpenBSD is never gonna be something like Qubes because Qubes needs things like VT-D and a boatload of memory/cores, it's never gonna be GrapheneOS because they can't rely on having MTE, TPM, etc. And that's fine.
They also deserve a lot of credit for contributions to the wider ecosystem as well. Just to give one example, making sure the OS can provide high quality entropy in all contexts with arc4random, which eventually percolated to FreeBSD, Linux, and even MacOS.
But sure, keep talking about the two holes if you want.
3 replies →
The base install includes a firewall, http server, load-balancer/proxy, ldap server, caching DNS resolver, ssh server, nfs server, dhcp server, smtp server, bgp routing daemon, virtual machine subsystem, and a lot of other stuff I'm probably forgetting.
7 replies →
OpenBSD was used under NDA's in some really sensitive corpos with Gnome2 setups and some RDP/Citrix clients and even Perl?+GTK2 wireless graphical assisatnt.
https://www.mtier.org/solutions/consulting/
If OpenBSD had a stable GeFS setup as a filesystem -still WIP- (and toad/hotplugd for external FS' mounting) it could get customers in no time, because today except for CUDA the rest can virtually work 100% the same as any Linux distro.
Cisco runs mostly Linux. Juniper uses freebsd and Linux.
1 reply →
I think there's this cultural bias about the 'boy genius open source coder' that of course isn't true at all. Open source code is at the same quality as corporate written closed source code, in general. There have been studies on this and open vs closed source code isn't very different in terms of defects and exploits.
The problem is the people most willing to buy into this cargo cult mentality are techies, so tech forums are the last place to really have this conversation based on facts. Hence why your comment is barely visible here due to its low karma.
> Windows
Known for its security. /s
> Cisco
Known for its backdoors. /s
Not that remarkable. Nobody in history has been able to write correct C code, and that includes OpenBSD developers.
I pointed an AI at the smallest two tools in OpenBSD I could think of, cat and find, and found multiple bugs. One of which was a buffer overflow (albeit unlikely to be exploitable). IIRC these bugs had existed since at least the NetBSD/OpenBSD split.
Everything in C is UB: https://news.ycombinator.com/item?id=48203698
I looked for bugs in Linux coreutils on a Russian Elbrus PC.
It has a very interesting protected mode of operation where every memory pointer is tagged.
So, I just ran tests and quickly found a number of memory-related bugs.
I’ve submitted some patches, but they were never accepted. These tools’ maintainers seemed very inertial to me. So maybe this is why many (low importance, I assume) issues persists there for a long time.
5 replies →
I feel like this is the elephant in the room. People keep acting surprised these large codebases are full of bugs and exploits. C isn't a safe language and moving to safe languages is going to be the only lasting solution.
1 reply →
>Nobody in history has been able to write correct C code
Except possibly D.J. Bernstein https://cr.yp.to/ ? Not necessarily all perfect, but designed for extreme simplicity and defense in depth, AFAIU.
6 replies →
Heavily audited might be a stretch. Who did the audit and what knew to look for is key. I wonder if they are using agentic tools to help improve the frequency and quality of their audits. Volunteer time is precious and getting robots to help might be useful, but I can also see it taking more of that same volunteer time to get good results from the robots. Either way, its their project and and they'll do as they deem fit, which is totally fine.
[flagged]
[flagged]
the ai-generated graphic before any content is presented is kind of a turnoff