?? 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.
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.
We're reaching levels of LLM dependency in the field where people just starting their careers in the last few years, now posting on HN, no longer have enough taste to judge writing or code quality.
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.
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.
It's a tricky balance. I certainly don't want my devices to have a ton of cruft installed which I would never need. But I also certainly don't want to have to spend a month after getting a new device just getting it into usable shape so I can use it for whatever I got it for. I used to think the second concern is very small since I do not get new devices that often, but turns out it's not true, it's often enough that I really want the OS to contain a lot of things from the start. OK, maybe not NetBIOS but wide enough device support and other capabilities so it would be useful for me. And if it's not, I - and most other technically competent, but busy people - would move on to something that provides that service. Goes double for people that are not technical, obviously.
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"
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.
To the point someone has made a talk validating the marketing with the actual reality,
"A systematic evaluation of OpenBSD's mitigations"
> OpenBSD markets itself as a secure operating system, but doesn't provide much evidences to back this claim. The goal of this talk is to evaluate how effective OpenBSD's security mitigation are, in a systematic, rational and comprehensive way.
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.
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.
It has needed some fixing over the years. errno was one thing. There have been a number of things in that vein, where Bernstein relied upon 1989 C or even K&R semantics and suchlike.
But compared to some other code from the 1990s, it has lasted the test of time quite well.
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://raw.githubusercontent.com/califio/publications/main/... contains comments, but they're extremely difficult for a human to understand. This reminds me of the process that video game speedrunners often use, and looks just like unintelligible wizardry to an outsider: 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.
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.
We're reaching levels of LLM dependency in the field where people just starting their careers in the last few years, now posting on HN, no longer have enough taste to judge writing or code quality.
(This will probably get me downvoted.)
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.
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.
It's a tricky balance. I certainly don't want my devices to have a ton of cruft installed which I would never need. But I also certainly don't want to have to spend a month after getting a new device just getting it into usable shape so I can use it for whatever I got it for. I used to think the second concern is very small since I do not get new devices that often, but turns out it's not true, it's often enough that I really want the OS to contain a lot of things from the start. OK, maybe not NetBIOS but wide enough device support and other capabilities so it would be useful for me. And if it's not, I - and most other technically competent, but busy people - would move on to something that provides that service. Goes double for people that are not technical, obviously.
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!
> They actively remove features and technically break standards to reduce surface.
Curious - what standards do they break, and why, in order to reduce attack surface?
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
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.
>And no, OpenBSD is not the most secure OS out there, and very few serious people claim it is.
My beef is that lots of uninformed people have been bamboozled into thinking it is more secure than it really is.
>But sure, keep talking about the two holes if you want.
Thanks for the go-ahead, I probably will.
To the point someone has made a talk validating the marketing with the actual reality,
"A systematic evaluation of OpenBSD's mitigations"
> OpenBSD markets itself as a secure operating system, but doesn't provide much evidences to back this claim. The goal of this talk is to evaluate how effective OpenBSD's security mitigation are, in a systematic, rational and comprehensive way.
https://media.ccc.de/v/36c3-10519-a_systematic_evaluation_of...
>> someone has made a talk validating the marketing with the actual reality
That was as of 6.6, circa 2019, to be clear. I'd be interested in what they would have to say about 7.9 at present.
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?
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".
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.
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.
So, not OpenBSD, then. I think we're on the same page.
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.
It’s clear from anyone trying to adopt MTE on ARM that there are just _a lot_ of memory-related bugs all over the place.
Yes. And they are mostly being considered to be unimportant by their maintainers.
Where did you report those coreutils issues?
To some mailing list and to some maintainers. As I recall it was also a separate report for tar. But it’s been 7 years already..
We take such reports seriously. I couldn't find any when searching again
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.
>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.
It has needed some fixing over the years. errno was one thing. There have been a number of things in that vein, where Bernstein relied upon 1989 C or even K&R semantics and suchlike.
But compared to some other code from the 1990s, it has lasted the test of time quite well.
* https://jdebp.uk/Softwares/djbwares/
He surely also had to face his share of C issues, here advocacy for "Boring C" in 2015,
https://groups.google.com/g/boring-crypto/c/48qa1kWignU/m/o8...
There have been exploitable vulnerabilities in DJB code.
His apps were some of the worst i've ever seen, usability wise.
As I understand, sacrifices were made to achieve the, for C programs, exceptional security.
No. I tried his code too.
Nobody.
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