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
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.
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.
in this case, it appears that a human did write it, and then you complained that it wasnt good.
a no-win situation, apparently.
They only audit the kernel and base userland. Ports are subject to far less scrutiny.
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.
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.
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.
... 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".
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.
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.
IMNHO more interesting than bickering over the "secure" label, is all the work openbsd has done and is doing to develop stuff like pledge.
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.
Both of these were logic bugs and not "insecure C code".
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.
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.
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
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.