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.
If it is, it's not very good. They provide the source for the exploit, great, but the explanation of the exploit is terrible: just seven pithy bullet points. It's not really clear what's going on without a lot more digging. The discussion of mitigations is better, though.
Context: I teach a college-level security class where undergrads do stack-smashing-like attacks (and every year a handful of talented students manage to pull off things like ROP attacks, analysis of entropy for a layout randomizers, or side-channel attacks). All of their writeups are much better than this one.
If, in this era of constantly dealing with overly verbose verbal diarrhea from LLMs, your complaint is that a human write up is too terse... then may I offer a simple cure: you can ask an LLM to turn it into as many pages of slop as you like.
Well, the key thing is that I don't want slop, period. I think a human should take the time and write it up. Honestly, my impression was the opposite-- it seemed like classic AI overly-jargony bullet point stuff.
I'm glad that people are using whatever tools are effective to find bugs, but if you expect a human audience to read about your findings, then is it not unreasonable to ask a human to write it? Most of the time a bug reveals a flaw in logic, and in operating systems, sometimes those logical flaws are informative, and lead to new and better designs, not just bug fixes. So there are potentially missed opportunities here.
It’s not no-win. It’s not sufficient to be a human! Be a better writer! There are plenty of good writers. The main difference between the bad ones and the good ones is that the good ones TRY to write better.
The point of the GPs comment wasn’t that there isn’t enough developers. It was that the OPs comment of “most heavily audited code bases” was an exaggeration.
There is another take on "heavily audited". Many OSs and eg. browsers have the issue that there are huge amounts of pretty complex codes. OpenBSD is extremely inviting and among actual general purpose operating systems used on a daily basis in production one of the projects that sees a quite big amount of reads because of the relative simplicity and (intentionally) low amount of code.
Really, try making sense of pretty much anything in the Linux kernel compared to the OpenBSD kernel or any of the bigger browsers. Like fully grasping it. There is worlds in between.
This has secondary effects of people actually looking at code that is not their area of expertise and developers also working outside their subsystems.
Meanwhile in eg Linux you have huge swaths of code that essentially only some guy in some company somewhere has somewhat of a grasp of. And that's where Linux constantly sees its vulnerabilities, while OpenBSD actively removes such things, eg they removed Bluetooth support back in 2014. This leads to a situation where people actually are able to dig into things. They also have a huge amount of guardrails turned on and I know people that compile their code on OpenBSD despite not targeting the OS at all because of those guardrails uncovering issues.
Think about any bigger software company. There is a huge chance you basically have no idea how the stuff outside your team works maybe not even all of your team.
These kind of are the attack vectors we see in Open Source all the time (and actually closed source software too). It's not the stuff that everyone uses and wants to understand deeply in browsers that cause exploits. It's that one tiny thing that is part of the standard or somehow support was added, but despite nobody using it it's still there, either because well.. it's a standard or because nobody bothered to remove it.
OpenBSD even decided to break some standards for security reasons, but that's another topic.
What I wanna say with that is: I can think of a lot of projects that have more devs and more people looking at parts of it, but these projects tend to be quickly changing huge codebases, where no single person can have a good understanding of everything. This means that there is a good likelyhood that parts are not audited until some group or individual comes along and picks such a bit.
It's actually also what likely happened in this case, given it's 37 years old.
This isn't to defend OpenBSD, but to point out that X amount of people doesn't mean much without taking the size of the audit into consideration. I would think that big projects is something where LLMs really shine, but I also think that reducing attack surface by reducing code and complexity might be the biggest defense and as far as I have seen OpenBSD does a great job there and should be considered something that others can learn from.
And it's not just these kinds of software. It's not even just software per se. It's also infrastructure, where complexity usually means increased attack surface. And just to be clear: One always adds complexity, but it should be the minimal amount to fulfill the goal and not more and try to not add side goals you don't actually care about and want to maintain.
Especially with LLMs it's so incredibly easy to add complexity only for tomorrow's LLM (or human) to find huge amounts of bugs.
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.
No language is safe, but I assume you mean memory safety in particular. Alternatives are to formally verify the C code to be memory safe or to add some memory safety features to C. Both certainly simpler and cheaper than rewriting everything.
Whether memory safety is really that important is also not clear. Most people get hacked because they run old software or insecure configurations. So a language such as Rust which creates more supply chain risks seems problematic.
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.
Sure, I don't disagree in principle with the idea that a smaller attack surface is better than a larger one, nor with the idea that explicitly enabling things is better than having to locate and disable services you didn't even know were running.
But saying "only two remote holes" gives the impression that all of OpenBSD is secure and that it's the most heavily scrutinized codebase in the world, it's bulletproof, etc.
It's not.
My toaster hasn't had a remote hole in a heck of a long time either, but then again it doesn't do anything other than make toast.
The default install of OpenBSD doesn't do anything, so the fact that it hasn't had a remote hole in forever isn't saying much.
I think one has to keep in mind where that slogan came from. A time where every OS tried to start a million services listening on the network, when OpenBSD ended up minimizing that, because it was aware of attack surface.
Nowadays it does the same with being very defensive of complexity and adding features just for the sake of it. They actively remove features and technically break standards to reduce surface. So while the phrase might be dated the whole idea of doing the minimal thing to provide minimal attack surface is something that some other projects could very much benefit from. Especially in times where people use LLMs that happily write ten classes instead of a simple five line function everyone can easily understand and verify.
Also I think it simply became a bit of a meme and like with the art and music it became a bit of a project culture thing. Don't overanalyze it. It's a joke like "days since last accident" and how Shodan is a video game reference and firewall probably came from some fantasy nerd. Hey, the term sharding came from a video game as well!
> 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.
... and if I were to guess, there's definitely backroom deals between the US government and Microsoft. There's no way all the phone home stuff is even included in "Windows for SCIF".
if you mean as in Windows phoning home in normal installations, a Windows Enterprise install stripped of most unneeded components with Group policy won't really "phone home"
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.
Yes, but with the exception of sshd (which you get asked about during install), none of these things (NONE!!!) is enabled by default.
I am probably misremembering, but the OpenBSD documentation used to even explain how to disable inetd if you were too paranoid to use that. It is now disabled by default, and--I just checked one of my running systems--my machine does not even have an /etc/inetd.conf file. Most of the things running on a default install are init, cron, slaacd, a handful of gettys, ntpd, syslogd, and sndoid. Arguably sndiod is the only thing you could really remove from that list.
But if you look at the security track record of opensmtpd, you'll quickly see that "Only two remote holes in the default install, in a heck of a long time!" Does not relate to the base system, but to the "default install" - that is; only sshd listening (and possibly pf).
IMNHO more interesting than bickering over the "secure" label, is all the work openbsd has done and is doing to develop stuff like pledge.
It doesn't matter as they are not enabled by default.
So even if they allow unauthenticated code execution as root or kernel by default when started, it would not count for the "remote hole in default install" claim.
You could as well just not enable network by default. Which makes Windows 95 safer than OpenBSD.
You're not being intellectually honest. Most of those things are disabled by default, so if the httpd had a remote hole, but was disabled by default, then that's not "pArT oF tHe DeFaUlT iNsTaLl" and thus not technically covered by their vaunted claims, and you know it.
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.
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.
Props for the OpenBSD Release -style graphics. Looking forward to the theme song.
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
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.
If it is, it's not very good. They provide the source for the exploit, great, but the explanation of the exploit is terrible: just seven pithy bullet points. It's not really clear what's going on without a lot more digging. The discussion of mitigations is better, though.
Context: I teach a college-level security class where undergrads do stack-smashing-like attacks (and every year a handful of talented students manage to pull off things like ROP attacks, analysis of entropy for a layout randomizers, or side-channel attacks). All of their writeups are much better than this one.
If, in this era of constantly dealing with overly verbose verbal diarrhea from LLMs, your complaint is that a human write up is too terse... then may I offer a simple cure: you can ask an LLM to turn it into as many pages of slop as you like.
Well, the key thing is that I don't want slop, period. I think a human should take the time and write it up. Honestly, my impression was the opposite-- it seemed like classic AI overly-jargony bullet point stuff.
I'm glad that people are using whatever tools are effective to find bugs, but if you expect a human audience to read about your findings, then is it not unreasonable to ask a human to write it? Most of the time a bug reveals a flaw in logic, and in operating systems, sometimes those logical flaws are informative, and lead to new and better designs, not just bug fixes. So there are potentially missed opportunities here.
>if you expect a human audience to read about your findings, then is it not unreasonable to ask a human to write it?
in this case, it appears that a human did write it, and then you complained that it wasnt good.
a no-win situation, apparently.
It’s not no-win. It’s not sufficient to be a human! Be a better writer! There are plenty of good writers. The main difference between the bad ones and the good ones is that the good ones TRY to write better.
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.
The point of the GPs comment wasn’t that there isn’t enough developers. It was that the OPs comment of “most heavily audited code bases” was an exaggeration.
There is another take on "heavily audited". Many OSs and eg. browsers have the issue that there are huge amounts of pretty complex codes. OpenBSD is extremely inviting and among actual general purpose operating systems used on a daily basis in production one of the projects that sees a quite big amount of reads because of the relative simplicity and (intentionally) low amount of code.
Really, try making sense of pretty much anything in the Linux kernel compared to the OpenBSD kernel or any of the bigger browsers. Like fully grasping it. There is worlds in between.
This has secondary effects of people actually looking at code that is not their area of expertise and developers also working outside their subsystems.
Meanwhile in eg Linux you have huge swaths of code that essentially only some guy in some company somewhere has somewhat of a grasp of. And that's where Linux constantly sees its vulnerabilities, while OpenBSD actively removes such things, eg they removed Bluetooth support back in 2014. This leads to a situation where people actually are able to dig into things. They also have a huge amount of guardrails turned on and I know people that compile their code on OpenBSD despite not targeting the OS at all because of those guardrails uncovering issues.
Think about any bigger software company. There is a huge chance you basically have no idea how the stuff outside your team works maybe not even all of your team.
These kind of are the attack vectors we see in Open Source all the time (and actually closed source software too). It's not the stuff that everyone uses and wants to understand deeply in browsers that cause exploits. It's that one tiny thing that is part of the standard or somehow support was added, but despite nobody using it it's still there, either because well.. it's a standard or because nobody bothered to remove it.
OpenBSD even decided to break some standards for security reasons, but that's another topic.
What I wanna say with that is: I can think of a lot of projects that have more devs and more people looking at parts of it, but these projects tend to be quickly changing huge codebases, where no single person can have a good understanding of everything. This means that there is a good likelyhood that parts are not audited until some group or individual comes along and picks such a bit.
It's actually also what likely happened in this case, given it's 37 years old.
This isn't to defend OpenBSD, but to point out that X amount of people doesn't mean much without taking the size of the audit into consideration. I would think that big projects is something where LLMs really shine, but I also think that reducing attack surface by reducing code and complexity might be the biggest defense and as far as I have seen OpenBSD does a great job there and should be considered something that others can learn from.
And it's not just these kinds of software. It's not even just software per se. It's also infrastructure, where complexity usually means increased attack surface. And just to be clear: One always adds complexity, but it should be the minimal amount to fulfill the goal and not more and try to not add side goals you don't actually care about and want to maintain.
Especially with LLMs it's so incredibly easy to add complexity only for tomorrow's LLM (or human) to find huge amounts of bugs.
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.
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.
No language is safe, but I assume you mean memory safety in particular. Alternatives are to formally verify the C code to be memory safe or to add some memory safety features to C. Both certainly simpler and cheaper than rewriting everything.
Whether memory safety is really that important is also not clear. Most people get hacked because they run old software or insecure configurations. So a language such as Rust which creates more supply chain risks seems problematic.
>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.
Sure, I don't disagree in principle with the idea that a smaller attack surface is better than a larger one, nor with the idea that explicitly enabling things is better than having to locate and disable services you didn't even know were running.
But saying "only two remote holes" gives the impression that all of OpenBSD is secure and that it's the most heavily scrutinized codebase in the world, it's bulletproof, etc.
It's not.
My toaster hasn't had a remote hole in a heck of a long time either, but then again it doesn't do anything other than make toast.
The default install of OpenBSD doesn't do anything, so the fact that it hasn't had a remote hole in forever isn't saying much.
I think one has to keep in mind where that slogan came from. A time where every OS tried to start a million services listening on the network, when OpenBSD ended up minimizing that, because it was aware of attack surface.
Nowadays it does the same with being very defensive of complexity and adding features just for the sake of it. They actively remove features and technically break standards to reduce surface. So while the phrase might be dated the whole idea of doing the minimal thing to provide minimal attack surface is something that some other projects could very much benefit from. Especially in times where people use LLMs that happily write ten classes instead of a simple five line function everyone can easily understand and verify.
Also I think it simply became a bit of a meme and like with the art and music it became a bit of a project culture thing. Don't overanalyze it. It's a joke like "days since last accident" and how Shodan is a video game reference and firewall probably came from some fantasy nerd. Hey, the term sharding came from a video game as well!
Your toaster does not run NetBSD? (-:
> 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.
... and if I were to guess, there's definitely backroom deals between the US government and Microsoft. There's no way all the phone home stuff is even included in "Windows for SCIF".
if you mean as in Windows phoning home in normal installations, a Windows Enterprise install stripped of most unneeded components with Group policy won't really "phone home"
and you can always just airgap the thing
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.
Yes, but with the exception of sshd (which you get asked about during install), none of these things (NONE!!!) is enabled by default.
I am probably misremembering, but the OpenBSD documentation used to even explain how to disable inetd if you were too paranoid to use that. It is now disabled by default, and--I just checked one of my running systems--my machine does not even have an /etc/inetd.conf file. Most of the things running on a default install are init, cron, slaacd, a handful of gettys, ntpd, syslogd, and sndoid. Arguably sndiod is the only thing you could really remove from that list.
Why should any of that be enabled by default?
The claim was that you had to install packages to make the system useful, but it in fact has a lot of useful stuff included.
The fact that vulnerabilities in the packages you mention wouldn't count towards the "2 remote holes" as they're not enabled in the default install?
But if you look at the security track record of opensmtpd, you'll quickly see that "Only two remote holes in the default install, in a heck of a long time!" Does not relate to the base system, but to the "default install" - that is; only sshd listening (and possibly pf).
IMNHO more interesting than bickering over the "secure" label, is all the work openbsd has done and is doing to develop stuff like pledge.
You're forgetting their SMTP server had a remote root RCE a few years ago, their IPSec server an authentication bypass, etc.
Both of these were logic bugs and not "insecure C code".
It doesn't matter as they are not enabled by default.
So even if they allow unauthenticated code execution as root or kernel by default when started, it would not count for the "remote hole in default install" claim.
You could as well just not enable network by default. Which makes Windows 95 safer than OpenBSD.
You're not being intellectually honest. Most of those things are disabled by default, so if the httpd had a remote hole, but was disabled by default, then that's not "pArT oF tHe DeFaUlT iNsTaLl" and thus not technically covered by their vaunted claims, and you know it.
Cisco runs mostly Linux. Juniper uses freebsd and Linux.
So, not OpenBSD, then. I think we're on the same page.
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.
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.
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.
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.
the ai-generated graphic before any content is presented is kind of a turnoff