Remember a little while ago when the AI shills announced the latest AI doom, doom, dooooom, DOOM.
A new model was really really great at finding and exploiting security holes. But, of course, in actual reality it could not do this on its own. An actual security researcher or actual hacker would have to go through the list of alleged holes and find those very very few of them that were actually holes.
Well, to my considerable surprise, it actually was very good at finding holes.
A bug has been found in linux that allows any process to gain root privileges. Which means you are at risk from malicious code in containers, it breaks out of containment. And it also means that remote code execution attacks, which you will probably get if you are running npm, can escalate from remote local user attack to remote root attack. And coding agents are also a risk — when they read the internet, which they frequently do, they are apt to treat instructions from the web page as instructions from the user, including instructions in hidden text, and local agents are allowed to run local user mode programs in user mode. The longer any single session runs, the more the agent is apt to be confused by things in the web pages that it has read.
You generally run npm and a coding agent as an unpriviled local user that can be easily and cheaply recreated for this reason. But now that local user can run at OS level.
The bug allows the attacker to modify the contents of files in memory, without effecting the file on disk. Including the data and code of operating system files running with unlimited privilege, and he can thus cause a system executable to grant him a root shell.
The kernel released a fix, but only now are the distributions finally updating.
Check your kernel name with uname -r
7.0, 6.19.12, 6.18.22, 6.12.85, 6.6.137, 6.1.170, 5.15.204, and 5.10.254 have been fixed.
Debian was among the first to issue the fix. Do an upgrade if running Debian.
Incorrect mitigation measures are being circulated, it will take a while to reliably know what actually works. Don’t believe what the AI tells you, it is likely to confidently propose a known bad fix.
The way you fix this is by formally modeling your system and making a correct by construction proof that your system excludes all the behavior you do not want. This of course cannot fix attacks on the hardware itself, like Spectre et al, but that is much harder to exploit at scale than a major kernel bug such as this.
The cryptographers were already about halfway here, and if they port the LLM harnesses to their already-made formal language systems, of which there are many, they can get the rest of the way. This is not a standard practice already mostly due to cognitive labor cost; it takes a lot of time and effort to make airtight logical models of the math we use in cryptography, and composing models to make a protocol is not trivial work. If we can automate this, at least partially, becomes cheaper. You can extend this from modeling protocols alone to modeling the behaviors of programs. You cannot prove everything about arbitrary programs but you should be able to prove certain behaviors such as “this subroutine does not access memory outside this bound.”
We should be taking this as a signal that the linux kernel is too much of a monolithic blob for modern practices being forced by LLMs, but the replacements, pragmatic hybrids between mono- and micro- kernels where certain operations like networking get direct kernel access and others like your USB driver devices do not, are not quite ready for general purpose hardware.
Jim, on the bitmessage rewrite:
I left it halfbaked some weeks ago. I could finish it, and faithfully reproduce all the data flows, but I am not willing to port anything to a formal model that can prove anonymity sets, that metadata does not leak, etc. Too much work for a system I won’t personally be making use of. What I can do is prove that the individual data flows are matched against the python reference implementation, and that the behavior looks identical from the outside. I wouldn’t be personally combing through much of the code, instead relying on behavioral tests, property tests, strong typing and leaning on extant libraries for cryptographic operations, and some finite state machine model checking.
I have a working specification extracted from the wiki, whitepaper, and code (including concrete datatypes, python functions for generating test vectors, etc), and a testnet composed of dockerized daemons of the python reference implementation. I was working on breaking the architecture components down and deciding on what tests to use and why when I moved on to something else.
Would you actually find use for this? You would have to go over my models and tests in order to decide if it is faithful enough to the reference to bother with. If you would actually use the new codebase and develop it further, I’ll return to working on the reproduction. If you would find it untrustworthy and not use it, I wont. Just let me know.