today at 3:41 PM
Props for the OpenBSD Release -style graphics. Looking forward to the theme song.
today at 3:17 PM
Interestingly, looks like this was accidentally fixed in NetBSD during a rewrite of that code in August of 1999.
today at 8:39 PM
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
today at 3:20 PM
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?
today at 3:41 PM
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
today at 4:06 PM
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.
today at 5:06 PM
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.
today at 6:04 PM
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.
today at 6:12 PM
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.
today at 6:43 PM
>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.
today at 8:32 PM
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.
today at 3:46 PM
It's not as heavily audited as you think. They have like a dozen active developers.
today at 4:40 PM
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.
today at 5:55 PM
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.
today at 8:19 PM
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.
today at 3:55 PM
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
today at 7:43 PM
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.
today at 5:22 PM
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.
today at 6:19 PM
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.
today at 4:22 PM
>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.
today at 4:59 PM
> 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.
today at 10:10 PM
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.
today at 6:47 PM
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.
today at 8:25 PM
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!
today at 7:59 PM
Your toaster does not run NetBSD? (-:
today at 5:44 PM
> 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".
today at 6:27 PM
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
today at 4:50 PM
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.
today at 5:14 PM
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.
today at 5:31 PM
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.
today at 5:39 PM
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?
today at 5:41 PM
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.
today at 5:10 PM
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".
today at 4:57 PM
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.
today at 6:42 PM
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.
today at 5:10 PM
Cisco runs mostly Linux. Juniper uses freebsd and Linux.
today at 6:49 PM
So, not OpenBSD, then. I think we're on the same page.
today at 5:11 PM
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.
today at 5:28 PM
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.
today at 4:08 PM
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.
today at 4:15 PM
[flagged]
today at 4:11 PM
[flagged]
today at 4:58 PM
Poor OpenBSD guys. Now they have to acknowledge THREE exploits (in total) on their homepage.
today at 5:33 PM
> 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.
today at 8:14 PM
the ai-generated graphic before any content is presented is kind of a turnoff