YHK - yet another hacker news clone

It's a bittersweet result, like finding asbestos in your house. I'd rather know than not, but I would much prefer not having it in the first place.

I understand this work was based on a dated snapshot. Will there be any continuous effort, scanning new PRs as they land, to prevent new weaknesses from being added?

I wish these blog posts included statistics on the categories of deficiencies that cause these vulnerabilities, and proposed measures to avoid them

A system that admits THOUSANDS of such vulnerabilities is certainly flawed in several fundamental aspects

As models get more advanced and generate an increasing throughput of increasingly higher quality results, how are you determining when to trust its results and when human review is needed on what?

E.g., 948 results is a high number to review in a timely manner unless your team is very large or spending several months combing through the results

EDIT: nvm i shouldve kept reading, answered

> At this scale, manually investigating every report is impractical for our research team. We therefore focused on validating findings that a) were reachable by a low-privileged user, b) required no special capabilities, and c) produced measurable evidence of memory corruption.

Thanks. I'm not a programmer so I can't understand what is happening in the kernel by looking at the changelog, so I'll ask: Are the problems remediated structurally so that nothing like it can occur in the future, rather than just patching it up? Are there "lessons learned" that are being applied and documented here (like, "this problem looks like it's shape transports to other subsystems as well, let's fix them all in a disciplined way")?

The high number is really impression to the point of making me skeptic. Are these distinct vulnerabilities or are a lot of the related in the way vulns often are?

The article says "The target virtual machines ran a stock desktop operating system". Are the vulns in the kernel specifically or does this include software running as root?

I'd like to see a break down by age of code and part of kernel (drivers, networking, core ,etc ..)

I'm going to assume that there was "old" code that caused LPE vulnerabilities, but, The Linux Foundation have their own project Sashiko (https://sashiko.dev/), which analyzes each commit to the Linux Kernel for bugs and vulnerabilities using Googles models, my question is then, how many of the vulnerabilities you found were also caught by Sashiko?

This has been true for DECADES.

Regular LPEs are not novel. The frequency has just increased a lot.

LPEs are frequent enough that people no longer use low-privilege user accounts to sandbox potentially malicious software. They are only used to control access for well-behaved users without any intent to subvert the system, not attackers.

The difference here reminds me of the distinction between the regular Paxos algorithm and the Byzantine Paxos algorithm.

> How did we get to the point where there are a thousand privilege escalation exploits in the kernel?

We developed AIs that can find them.

How can it be surprising that a software made from 40+ million lines of memory-unsafe code has hundreds of critical bugs?

The dirty secret is multi-user died in the 90s and privilege escalation has basically been considered table-stakes since then.

> Should we assume that all software is more compromised than the kernel?

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.

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.

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.

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 Datamation magazine.

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.

So that's my conclusion of how we got here: We've always been here.

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.

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.

> How did we get to the point where there are a thousand privilege escalation exploits in the kernel?

it's been rule of thumb basically forever that there is 1 bug per ~10KLOC for any project

linux kernel is millions of lines, so thousands of bugs being hidden there is about on point

(tho obviously far smaller serious escalation ones, obviously, but you're exaggerating as well)

>Is the kernel simply too complex to reason about? Is it an underlying flaw in the security model or language implementation?

There is nothing magical about kernel. Look at the code anywhere and it has bugs, lots of them.

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.

Give it time and they accumulate

Because the large corporations that fund Linux development and use Linux value speed over security.

Speed requires a lot of code in the kernel, where that code can run fast.

There are kernels that do not have a thousand privilege escalation exploits. These kernels are smaller and much easier to check for bugs. But those kernels are significantly slower.

For many use cases, slower is not a problem. But for the large corporations who fund a lot of Linux development and use Linux in large data centers, every 1% slower can literally be millions of dollars worth of additional servers that are required.

OpenBSD shows that you can have a Unix security model without a thousand privilege escalation exploits. But OpenBSD is like 10% slower. So corporations won't use it because it would cost millions of dollars more per year and some of their software requires access that OpenBSD does not grant precisely because that access leads to security exploits (i.e. io_uring, eBPF etc. etc.)

You could also use like seL4, but that's slow too

So that's why. It's a business tradeoff between cost of servers vs cost of getting hacked, and cost of servers wins.

amazing things happen when you decide that device drivers should be a part of your kernel codebase

Many people seem to be making this about their pet issue, but "these systems are complex" and "the frontier labs have developed models that are superhuman at hacking" seems like a totally sufficient explanation.

I've been working with a LoRa chip called the LR2021. I plugged a dev board into my computer and told Claude to reverse engineer it. He dissected it with a speed and level of efficiency I couldn't believe. Within a few hours, Claude was writing custom patches for a completely opaque patch RAM area meant only for the manufacture. I wrote about it here: https://beala.substack.com/p/your-node-doesnt-need-a-microco...

Yes, you should assume that all software you use is full of holes, and after we patch all the holes that could conceptually have been discovered by a motivated human, there will still be holes that can only be found by considering larger windows of context than any human has or could. Even when something is formally verified, that doesn't extend to its software environment or the hardware it's running on, and those can introduce exploitable vulnerabilities as well. You can only ever be very confident that we've found all the holes at a given analysis capability level -- if something a hundred times as capable looks, it will likely find many more. That's how it will be.

Human brain mostly take the shortest available path for a solution to reduce the cognitive load. When a system complexity increases probability of cutting the corners will get increased. This is a known pattern. Models just do the polar opposite. They try to cover almost every hypothetical edge cases. They never get tired or bored, nor do they suffer from glucose limits, mental fatigue, or shifting attention spans, which is one cause of over engineering, but valuable in vulnerability tracing.

There are a lot of LPE's in Windows too. Remember that it started out as a single user operating system, it took a long time to get software on board to not always running as admin.

The governments buy them up [1]. Nukes wouldn't be required for WW3.

[1] https://www.cyberdefensemagazine.com/zero-day-market-the-gov...

In general computer systems have been known unreliable since the 1980s, especially when networked. The entire cyber security industry operates not by preventing intrusions in the first place, but by rapidly mitigating them when they inevitably happen.

Hopefully this type of work to automatically discover & patch vulnerability leads to much more reliable software, and the remove the need for cyber security.

Oh no, they will not be secured against their own users :(