sure, but with unsafe Rust you have a very clear marking for the section of code that requires additional care and attention. it is also customary to include a "SAFETY" comment outlining why using unsafe is OK here

But one would have to explicitly choose to use unsafe Rust for this instead of ordinary safe Rust. And safe Rust has no particular difficulty writing to slots in an array or slice or vector specified by their index.

That's not prevention. That's remediation.

Surely nobody could create a better language in 50 years. Surely we can't fix these issues.

It has been available in Apple's version[1] for several years, and it appears to be migrating into upstream as well.

On macOS you can try it with:

    clang -Xclang -fbounds-safety program.c

Microsoft also seems to be using it (see above link regarding lib0xc).

[1] https://github.com/swiftlang/llvm-project

You're kind of making my point. Perhaps we will see a trend where support for many things are not available by default and need to be installed as needed. Linux doesn't need to come with support for this and that (like AX.25) when it can be installed in seconds if truly needed. Doesn't OpenBSD already take this approach?

I agree. It is not like Mythos or other LLMs are insanely smart/superhuman. Many of these vulnerabilities could be discovered fairly easily by trained human experts as well. The problem is more that it requires an insane amount of attention and time of highly-paid experts to shake out these issues vs. an LLM that never gets tired and can analyze a large amount of code at low cost.

Linus' law was wrong because there were never enough (qualified) eyeballs to check the code. LLMs provide an ample supply of eyeballs (though it's not a benefit to open source, since proprietary developers can use the same LLMs).

Same applies to them being good enough to program, but many are so focused on source code generation that they don't get the whole picture.

Thanks to agents and tool calling, there are now business cases that can be fully described by AI tooling, the next step in microservices, serverless and what not.

Naturally with a much smaller team than what was required previously.

AI assistance was explicitly disclosed on yesterday's. Today's has Claude as one of two contributors on this GitHub Pages site at least so it's also very likely.

Agents are capable of finding this kind of stuff now and people are having a field day using them to find high-profile CVEs for fun or profit.

You're probably right, but that seems like the less important part of this. At that point you've already got an out-of-bounds write. Another comment speculated that you could use PageJack as an alternative exploit path once you have that primitive: https://news.ycombinator.com/item?id=48069623

No, that depends on the kind of privilege check.

Some codepaths do ns_capable() (must have capability in owning namespace, reachable via unprivileged user namespaces), some do capable() (must have capability in host user namespace, not reachable via user namespaces at all).

ZCRX can only be enabled by passing capable(CAP_NET_ADMIN), so you need to be privileged on the host.

Namespaces _may_ result in limits on what you can do with a capability, but a capability is global in scope.

If a kernel feature is gated on cap_sys_admin only, it doesn't matter at all what namespace it is in. Namespace support or additional constraints are not implicit and have to be added to each need.

People misunderstanding this is partially why we have this latest crop of vulnerabilities.

1) the various projects refused even simple requests like allowing the admin to disable the —privileged flag, in the rootfull days. 2) The choice to break out CRI will zero authorization or mutations at the CRI level, while understandable to the containerd teams needs, exposed every other runtime to an unprotected alternative communication path. 3) The OCI groups refusal to provide guidance to LSM maintainers as to minimal configurations, while also handling the responsibilities of seccomp profiles to end users means only actively attacked vectors are protected and it becomes impossible for normal users to operate safely. 4) under the UNIX model it is the caller to clone/fork/unshare that must drop privileges. 5) This model was set in concrete by the OCI standards and now suffers from the frozen caveman pattern.

The capable()[0] syscall operates as one would expect for granting superior capabilities, and while the work to expand the isolation is something I am sure you are familiar with, you probably also realize that the number of entries in a default user also expanded just to support user namespaces.

But to be clear, the choices that docker/oci made are understandable from a local greedy choice perspective, it complicates the entire user space.

K8s mutating inlet controllers are a symptom of those choices.

Had a CRI contained a bounding set, enforced at a system level, especially with guidance and tools for users to use a minimal set, which they could expand on easily we would be in a better spot.

But as other projects cannot provide meaningful protections that cannot be simply bypassed by calling privileged CRIs it is also a barrier to convincing them to do the same.

Really there is a larger problem that OCI could be the leader on, but they are the ‘killer app’ and refuse to do so.

The bounding set for user capabilities is driven by containers, and while namespaces are not and never have been a security feature, this blocks their ability to have a strong security posture.

To be clear, expecting every end user to write minimal seccomp profiles is unrealistic, especially when docker prevents devs from accessing the local machine to discover what is happening. I think podman is the only machine that allows that by default.

Basically while simplifying moby/containerd/CRI is an understandable choice, the refusal to address the costs of that local optim has fallout

[0] https://elixir.bootlin.com/linux/v7.0.5/source/kernel/capabi...

Yes, it's a fork of Fedora. https://docs.aws.amazon.com/linux/al2023/ug/what-is-amazon-l...

However, some privs can be gained in namespaces/unshare.

I do think SELinux is a good example of how robust software with poor UX/DX gets undermined by that poor UX/DX. Although I do wonder if AI can help with it?

It is enabled by default on Android, and only developers can change it temporarly via an ADB session.

The Anthropic researchers have said their flow is as simple as:

1. Pick a file to seed as a starting place.

2. Ask the LLM (in an agent harness) to find a vulnerability by starting there.

3. If it claims to have found something, ask another one to create an exploit/verify it/prove it or whatever.

4. If both conclude there is a vuln, then with the latest models you almost certainly found something real.

Just run it against every file in a repo, or select a subset, or have an LLM select files with a simple "what X files look likely to have vulns?".

So basically yes, it is that simple. It's just a matter of having the money to pay for the tokens.

Pray to God no one ever lets an AI agent run loose on the various leaked Windows source code dumps.

Given Windows' absurd amount of backwards compatibility, chances are pretty high that there are a lot of sleeping dragons buried inside even modern Windows 10/11 kernel and userland that date back to code and issues from the 90s - code where half the people who have worked on it probably not just have departed Microsoft but departed living in the meantime.

That's significantly more challenging for an LLM (and a human)

Security through obscurity

Something something microkernels + capability-based security.

> for years now ZCRX is less than half a year old. I'm so tired boss.

You actually kind of don't, I use like a zillion crates which have unsafe Rust in them and it's not like I'm sitting here reading every single line of their code. I like Rust for various reasons, but its memory safety is (imo) overstated, especially when doing low-level stuff.

If I was NSA I'd heavily use this feature on my farm in Utah :^)

Static analysis and other tools can find this, but they're expensive; wonder what the kernel team has access to?

except nearly everyone uses unsafe rust

It's possible I had seen that blog post and not remembered! I was intending to reference the Onion though (and even googled to make sure I had the wording right), but seeing someone else make the same joke and forgetting is certainly something I would do

Hubris, an embedded RTOS-like used in production by Oxide, has ~4% unsafe code in the kernel last I checked. There’s a ring buffer implementation that has one unsafe, for unchecked indexing: https://github.com/oxidecomputer/hubris/blob/master/lib/ring... (this of course does not mean that it is the one ring buffer to rule them all, but it’s to demonstrate that yes, it is at least possible to have one with minimum unsafe.)

It’s always a way lower number than folks assume. Even in spaces that have higher than average usage.

I doubt it, but you can probably get pretty close.

This is something a lot of people misunderstand about unsafe rust. The safe / unsafe distinction isn't at the crate level. You don't say "this entire module opts out of safety checks". Unsafe is a granular thing. The unsafe keyword doesn't turn off the borrow checker. It just lets you dereference pointers (and do a few other tricks).

Systems code written in rust often has a few unsafe functions which interact with the actual hardware. But all the high level logic - which is usually most of the code by volume - can be written using safe, higher level abstractions.

"Can all of io_uring be written in safe rust?" - probably not, no. But could you write the vast majority of io_uring in safe rust? Almost certainly. This bug is a great example. In this case, the problematic function was this one:

    static void io_zcrx_return_niov_freelist(struct net_iov *niov)
    {
        struct io_zcrx_area *area = io_zcrx_iov_to_area(niov);

        spin_lock_bh(&area->freelist_lock);
        area->freelist[area->free_count++] = net_iov_idx(niov);
        spin_unlock_bh(&area->freelist_lock);
    }

At a glance, this function absolutely could have been written in safe rust. And even if it was unsafe, array lookups in rust are still bounds checked.

> Doing unsafe stuff is pretty inevitable if you want to do anything non-hello-world-ish.

So the vast majority of Rust projects involve writing at least one unsafe block? Is that really your claim?

Making use of win32 functions doesn't turn off bounds checking in your rust code.

A tiny fraction of programs need to use win32 or Mac OS functions beyond the standard library or other safe wrappers for said functions.

So what? Just because you used the keyword `unsafe` to call an unsafe API does not mean that you are going to use unsafe pointer access to write to a vector.

The thing is you can actually write quite good C code (see OpenBSD project). The power of C is that it's pragmatic. It lets you write code with you taking the full responsibility of being a responsible person. To err is human, but we developed a set of practices to handle this (by making sure the gun is unloaded and the safety is on before storing it to avoid putting holes in feet).

I like type checking and other compile time checks, but sometimes they feel very ceremonial. And all of them are inference based, so they still relies on the axiom being right and that the chain of rules is not broken somewhere. And in the end they are annotations, not the runtime algorithm.

It seems like you have this backwards. Messing up lifetimes in safe Rust can't cause unsafety; the compiler checks if the lifetimes are valid, and if they're not, you get a compiler error. You don't need to "hope" you did it right because the entire point is that you can't compile if you didn't.

On the other hand, when you're relying on your ability to "actually write quite good C code"...you'd better hope that you have not made an error there. In practice, some of the most widely used C libraries in the world still seem to have bugs like this, so I don't really understand why you'd think that's a winning strategy.