How did we get to the point where there are a thousand privilege escalation exploits in the kernel?<p>Is the kernel simply too complex to reason about? Is it an underlying flaw in the security model or language implementation?<p>Should we assume that all software is more compromised than the kernel?
> Should we assume that all software is more compromised than the kernel?<p>Absolutely, the front door has always been unlocked. We were previously protected by the economics of exploit detection favoring the developers, but now we have entered a new world.<p>The issues arise almost everywhere we look. It's frustrating because the user experience in edge systems has barely changed in the last fifteen years. We could have rode the advances in semiconductor manufacturing to embed more layers of protection such as CHERI while slightly slowing down the rate of performance improvements. Instead we have only marginally upgraded security and largely added features which the users scarcely notice.<p>I am hopeful about the long term prospects of formal verification, but having humans reviewing the proof statements and confirming they match our desired properties will take many years. Meanwhile, AI assisted hacking is an urgent issue. So we will have to delegate implementation, proof specification, and proof development to the AIs in the short term. Maybe that goes well, but who knows. Interesting times.
For all of my time being aware of this industry, it has generally been understood that privilege escalation bugs are common. This has always been a thing. A lot of people say, commonly and for many years, that if your security depends on there not being privilege escalation bugs, you don't have security.
>Is the kernel simply too complex to reason about? Is it an underlying flaw in the security model or language implementation?<p>There is nothing magical about kernel. Look at the code anywhere and it has bugs, lots of them.<p>Security bugs are just bugs. More often than not they are silently there and don't prevent you from using the software and you can't react and fix them because of that.<p>Give it time and they accumulate
The dirty secret is multi-user died in the 90s and privilege escalation has basically been considered table-stakes since then.
> How did we get to the point where there are a thousand privilege escalation exploits in the kernel?<p>it's been rule of thumb basically forever that there is 1 bug per ~10KLOC for any project<p>linux kernel is millions of lines, so thousands of bugs being hidden there is about on point<p>(tho obviously far smaller serious escalation ones, obviously, but you're exaggerating as well)
The kernel has the problem that basically every bug in it is also a security vulnerability. All software has bugs. Had Linux been written in Rust, and I strongly recommend a rewrite, it would still have bugs, and thus would still have vulnerabilities. But they'd be way less.
> and I strongly recommend a rewrite,<p>Oh, you strongly recommend rewriting tens of millions of lines of code? Why don't you do it yourself? Just a prompt away, right?
fwiw at work we've been looking at what the options are more memory-safe kernels out there. Not many options. If there were a "safe linux" maintained by like canonical or redhat or whatever we'd use it. For datacenter workloads like sandboxes and virtualization I think it'd do well.
Kernel will eventually move to rust, but not the dramatic and fast way
“Claude rewrite this project, its 40 million LOC, make no mistake”
How can it be surprising that a software made from <i>40+ million lines</i> of memory-unsafe code has hundreds of critical bugs?
More than half of those lines are from drivers, drivers which wouldn't be relevant to a VM environment. Core kernel code for any particular architecture is less than 10 million, but some of that is filesystems or subsystems not in use or available to an unprivileged user on a typical server, so possibly maybe 5 million or less. And the article says they only targeted 2.8 million SLoC.
There are always more left.
Funny how OpenBSD is "memory-unsafe" yet doesn't have these issues. Could it be that <i>the programmer</i> might have something to do with it?
As an OpenBSD lover and frequent user I will tell you it does not support but a significant fraction of the hardware Linux does, and has many features that are reduced in functionality or just gone compared to Linux.<p>Is it bulletproof? Definitely! But you need the genius of Albert Einstein as well as the patience of Mother Theresa to actually use it in production.
Can't have a bug in a feature you never implemented and can't have another arising from unexpected interaction of two features you didn't implement.<p>It's the one security practice that actuuuualy works
For most server setups OpenBSD's hardware support is adequate, and this is especially true for VMs. It's laptops, peripherals, and bleeding edge, high-performance or specialized devices where driver support is a PITA. But that's not something I've encountered running my own private servers. It would be nice to have something like ZFS, but mostly that's a peace and convenience thing--would be nice to be able to stream backups somewhere rather than push around dumps and tarballs, though I have a script for that.
Is anyone spending millions of dollars on checking OpenBSD?<p>But it also got its share of use-after-free and OOB access vulnerabilities this year: <a href="https://feedly.com/cve/vendors/openbsd" rel="nofollow">https://feedly.com/cve/vendors/openbsd</a>
> Funny how OpenBSD is "memory-unsafe" yet doesn't have these issues.<p>First of all... Do you really believe that to be true?
I recall reading that every IBM mainframe OS release had 1000 bugs in it. (This was in the 1970s/80s.) Sorry I can't supply a source, after 4-5 decades. It was probably an article in <i>Datamation</i> magazine.<p>Now, I don't know how many of those bugs were privilege escalations, or could be leveraged to be. I'm not sure that people tried to exploit in the same way back then (or, if they did, if they said anything publicly about the results). Still, even if the majority of those bugs were not exploitable, OSes were much smaller then.<p>So that's my conclusion of how we got here: We've always <i>been</i> here.
> How did we get to the point where there are a thousand privilege escalation exploits in the kernel?<p>We developed AIs that can find them.
> How did we get to the point where there are a thousand privilege escalation exploits in the kernel?<p>> > We developed AIs that can find them.<p>We could already find them before AI.<p>We already knew they were there, and we already knew how to prevent them in the first place.<p>See previous discussion: <a href="https://news.ycombinator.com/item?id=49705794">https://news.ycombinator.com/item?id=49705794</a>