Big Fish: Exploiting a 37-Year-Old Kernel Bug in OpenBSD (calif.io)

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.

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.

and you can always just airgap the thing

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!