hckrnws

Better to follow the link to the technical details and just read those: https://cdn2.qualys.com/advisory/2026/03/17/snap-confine-sys...

The article linked in the submission is more verbose but less clear and half of it is an advertisement for their product.

I love that cheeky "oh btw, there's also another vulnerability in rust coreutils rewrite, but we aren't talking about that" paragraph

But this vulnerability is enabled by a very creative exploitation of the complicated bind mounting scheme used by snap-confine. Just reading about these mounts between /usr/lib to /tmp and back triggered my sense of a potential security vulnerability.

That's because it's not a vulnerability per se. They found a way to use `rm` as a gadget for their privilege escalation.

The core problem is that there's a world-writable directory that is processed by a program running as root.

It's a race condition that can be used as a primitive to achieve privilege escalation which makes it legitimate but even if it you couldn't use it for anything else but to trick the system into acting on a directory it didn't meant to it would still be a valid vulnerability (regardless of the application).

Claiming it's not a valid bug would be similar to claiming an infoleak isn't as well when it's one of the building blocks of modern exploitation.

I'm not trying to be an ass, I'm just trying to add a bit of context to ensure that the implication is well understood.

This.

Might be worth updating the link.

> As a side note, we also discovered a local vulnerability (a race condition) in the uutils coreutils (a Rust rewrite of the standard GNU coreutils -- ls, cp, rm, cat, sort, etc), which are installed by default in Ubuntu 25.10. This vulnerability was mitigated in Ubuntu 25.10 before its release (by replacing the uutils coreutils' rm with the standard GNU coreutils' rm), and would otherwise have resulted in an LPE (from any unprivileged user to full root) in the default installation of Ubuntu Desktop 25.10.

Shurely Shome mistake, not a vuln in holy rust!

Rust cannot help you if race condition crosses API boundary. No matter what language you use, you have to think about system as a whole. Failure to do that results in bugs like this

The bigger problem here is it seems like the rust utilities were rushed to be released without extensive testing or security analysis because simply because they are written in rust. And this isn't the first serious flaw because of that.

Doesn't surprise me coming from Canonical though.

At least that's the vibe I'm getting from [1] and definitely [2]

[1] https://cdn2.qualys.com/advisory/2026/03/17/snap-confine-sys... [2] https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bu...

The best discussion I can find for the official reasons for switching is https://discourse.ubuntu.com/t/carefully-but-purposefully-ox... -

> But… why?

> Performance is a frequently cited rationale for “Rewrite it in Rust” projects. While performance is high on my list of priorities, it’s not the primary driver behind this change. These utilities are at the heart of the distribution - and it’s the enhanced resilience and safety that is more easily achieved with Rust ports that are most attractive to me.

> The Rust language, its type system and its borrow checker (and its community!) work together to encourage developers to write safe, sound, resilient software. With added safety comes an increase in security guarantees, and with an increase in security comes an increase in overall resilience of the system - and where better to start than with the foundational tools that build the distribution?

So yes, it sounds like the primary official reason is "enhanced resilience and safety". Given that, I would be interested in seeing the number of security problems in each implementation over time. GNU coreutils does have problems from time to time, but... https://app.opencve.io/cve/?product=coreutils&vendor=gnu only seems to list 10 CVEs since 2005. Unfortunately I can't find an equivalent for uutils, but just from news coverage I'm pretty sure they have a worse track record thus far.

probably because many of those tools were around for 20ish years before 2005

fileutils-1.0 was released in 1990 [1]. shellutils-1.0 was released in 1991 [2], and textutils-1.0 was released a month later in the same year [3].

Those three packages were combined into coreutils-5.0 in 2003 [4].

[1] https://groups.google.com/g/gnu.utils.bug/c/CviP42X_hCY/m/Ys... [2] https://groups.google.com/g/gnu.utils.bug/c/xpTRtuFpNQc/m/mR... [3] https://groups.google.com/g/gnu.utils.bug/c/iN5KuoJYRhU/m/V_... [4] https://lists.gnu.org/archive/html/info-gnu/2003-04/msg00000...

It's extremely early to say if things are rushed or not. It's unsurprising that newer software has an influx of vulnerabilities initially, it'll be a matter of retrospectively evaluating this after that time period has passed.

> influx of vulnerabilities initially

https://en.wikipedia.org/wiki/Bathtub_curve

It's a little different with software since you don't usually have the code or silicon wearing out, but aging software does start to have a mismatch with the way people are trying to use it and the things it has to interact with, which leads to a similar rise of "failure" in the end.

It's not even about API boundaries, it's about logic and the language isn't really responsible for that.

Expecting it to prevent it would be as gullible as expecting it to prevent a toctou or any other type of non trivial vulnerability.

That's why even though I appreciate the role of these slightly safer languages I still have a bit of a knee-jerk reaction to the exagerated claims of their benefits and how much of a piece of crap C is.

Spoiler, crappy programmers write crappy code regardless of the language so maybe we should focus on teaching students to think of the code they're writing from a different perspective and focus safety and maintainability rather than "flashiness"

You wasted your generational revolution capital into creating an interesting new language with a concept of ownership, but you didn't think of applying it past the program boundary?

There's a class of developers that think that the program they are writing is the whole world. Didn't think rustaceans would be in that space. Maybe the Rust variant is that their program will go down the stack until everything is part of Rust, rather than being based on ignorance and naivety.

Rewrite tools in new language, get new exciting bugs!

That's optimistic. Use a search engine to find:

   JWZ CADT

> (a Rust rewrite of the standard GNU coreutils -- ls, cp, rm, cat, sort, etc), which are installed by default in Ubuntu 25.10.

0 benefits and only risks involved. Users are forced to choose between a worse new version or an older version that will no longer be supported. Like SystemD all over again.

It feels like there is a phenomenon where software devs (especially Open Source) have to keep developing even when just doing nothing would result in a better product. Like there's some monetization incentives to keep touching the thing so that you can get paid.

Is a race condition a memory related error?

No. Race conditions are a normal part of our world, in the same way it's not a memory error if you coded the discount feature so that people can apply more than one 10% off coupon to an order and as a result the nine different "10% off" offers that marketing seeded have summed to a 90% discount which bankrupts you.

An example race condition would be Mike and Sarah both wake up, notice there's no milk and decide to grab milk on the way home that evening, they both work a full day, drop past the store and arrive home with a carton of milk. But, now there are two cartons of milk, which is too much milk. Oops. This is called a "Time of Check versus Time of Use" race or ToCToU race.

(Safe) Rust does prevent Data Races which can be seen as a specific very weird type of Race Condition, unlike other race conditions a Data Race reflects a difference between how humans understand computers in order to write computer software and how the machine actually works.

Humans are used to experiencing a world in which things happen in order. We write software for that intuitive world, this is called "Sequential consistency". A happens before B, or B happens before A, one of these must be true. Mustn't it? But actually a modern multi-core CPU cannot afford sequential consistency, we give that up for more speed, so any appearance of sequential consistency in concurrent software is an illusion for our comfort. (Safe) Rust promises the illusion is maintained, if you try to shatter it the compiler is going to say "No", languages like C or C++ just say well, if you accidentally destroy the illusion your program might do absolutely anything at all, good luck with that.

Not this particular kind. This is a race between separate processes, and the target is the file system, not a location in memory.

It can be about any resource. You get it when two concurrent functions access the resource without a queue, atomic operation or wait, and one of them modifies it.

I wonder if, and this is just speculating not trying to start an arguement, if this sort of thing could have happened in the simpler pre-snap, pre-systemd systems? More to the point is this a cause of using more complicated software?

Without snap, the front door is wide open: all applications you run are unconfined within your user account and can snoop on all of your files. On a normal single-user desktop system, almost everything valuable is within your user account, not root. If an attacker does want root (such as to install a rootkit that can hide itself or to access other user accounts), they can install an alias to sudo on your account and piggy-back on the next time you use it.

Well yeah, if everything runs unsandboxed as root then there are no privilege escalations!

Less pithy, i seem to recall many issue with programs that relied on suid and permission dropping, which would be the 'oldschool' way of firming up the above.

You're not wrong that complexity has been introduced, and I'm not a a fan of snap either, but ultimately sandboxes (esp backwards compatible ones that don't need source level modifications) are complex.

If you want simple and secure, you're probably looking at OpenBSD and pledge.

I think a better question is whether there are simpler approaches to sandboxing applications that avoid this problem by design.

The answer is definitely "yes". Many articles and books have been written about UNIX administration, and separating accounts, even without jails.

With jails, you could do even better.

This isn't really systemd's fault at all. Systemd just happens to be what cleans up /tmp. You would have the same problem with tmpreaper.

The problem is snapd not protecting against something else writing to /tmp.

Permission and timing gotchas in /tmp predate snap and systemd. It's why things like `mkstemp` exist.

I remember cron jobs that did what systemd-tmpfiles-clean does before it existed. All unix daemons using /tmp run the risk of misusing /tmp. I don't know snap well enough to say anything about it makes it uniquely more susceptible to that.

The mistake seems to be using a predictable path (/tmp/.snap) in a publicly-writable directory.

The exploit doesn't rely on the path being predictable though.

As I read it the .snap is expired and pruned, then the exploiter makes their own .snap in /tmp, then snap-confine assumes that the new .snap is the old one and executes with elevated privileges.

So, the path can be from mkstemp, or a sha-256 of your significant others fingerprint, it doesn't matter; until it expires it's plaintext in the /tmp listing.

{Wild, ignorant speculation follows ... hashing the inode and putting a signed file in the folder bearing that hash, then checking for that ... something that works but along those lines might be appropriate. (We know the inode for the 10 days we're waiting for /tmp/.snap to get pruned; time that might be used to generate a hash collision, so my off-the-cuff suggestion is definitely no good. It feels like there's a simple solution but everything I can think of fails to KPA, I think -- perhaps just use dm-crypt for the /tmp/.snap folder?}

Yes, it does. The attacker knows that snap is going to look in /tmp/.snap/, instead of e.g. /tmp/.snap.FjBz8oEWaU/ (which isn't guessable in advance) so when /tmp is flushed, he just has to recreate /tmp/.snap/ before snap-confine does, and drop his payload there.

If the directory had a random name, the attacker could see that name and recreate it after /tmp is flushed.

Or just assert the UID and GID of /tmp/.snap before using. Of course, you'd want to open(2) /tmp/.snap and use fstat(2) on a descriptor (not just pass the path, /tmp/.snap, to stat(2)), then use mkdirat, openat & friends consistently.

Seems to address the proximal issue but perhaps leaves open use in a chaining attack?

Semi-related: does anybody know of a reliable API that announces CVEs as they're published?

Edit: for others who may be curious https://www.cve.org/Downloads

They publish on GitHub now https://github.com/CVEProject/cvelistV5

If you need metadata added by NVD, NVD website documents their API.

systemd-tmpfiles bugs the heck out of me. It breaks so many applications for absolutely no good reason. A typical system of mine not running it gathers less than 1GiB per year of uptime in /tmp with disk sizes measured in TB. Even if you are /tmp on a 256GB NVME, that's less than 1% of your total disk per year of uptime. If you upgrade to alternating Ubuntu LTS editions (which requires a reboot every 4 years) systemd-tmpfiles will save you a maximum of 4GB of disk space.

If you care about slow tmp leaks, you could also just use a 1-line, decade+ old solution; no additional software required, since your machine already has cron, find and xargs on it:

https://askubuntu.com/questions/431058/using-a-cronjob-to-cl...

If you miss that "will this eat my system?" adrenaline rush you get from systemd-tmpfiles, you could just use cron + find, but replace xargs with the -delete option.

I always wonder why Ubuntu is even on the radar anymore. It is a pile of questionable decisions with a billionaire ego bus factor. If you like apt, just use Debian. sid is fine for desktops if you are moderately technical.

Debian is almost as broken as Ubuntu.

However, I've been extremely happy with Devuan. It is Debian minus some bad decisions the Ubuntu voting block forced upstream (for instance, there's no systemd).

The shared /tmp/ directory that can be used by processes of multiple users seems extremely prone to causing this type of issue. I wish there was a common convention for user-specific temp directories on Linux, because a whole class of vulnerabilities could go away.

MacOS handles this great by setting $TMPDIR to some /var/folders/.../ directory that's specific to the current user. Linux does have something similar with $XDG_RUNTIME_DIR (generally /run/user/$UID/), though it's stored in memory only which is a little different from usual for /tmp/, seemingly mainly intended for small stuff like unix sockets.

> Linux does have something similar with $XDG_RUNTIME_DIR (generally /run/user/$UID/), but it's stored in memory only

On a lot (at this point I assume most) of systems /tmp is also just a tmpfs, so it also is just in memory. /var/tmp usually is storage backed though.

> I wish there was a common convention for user-specific temp directories on Linux

There kind of is. /run/user/$userId is part of a tmpfs and is owned by the user. But it isn't always used when it should be.

Systemd also has a mechanism to create private /tmp directories for services.

which of course raises the question why the fuck snap doesn't use either of these mechanisms?

It is possible to just not use snap on ubuntu. The few ubuntu servers we have, even the couple with a minimal XFCE interface for some gui pieces, don't have snap installed. I realise local exploits happen all the time, but why add a whole new huge surface area if I don't have to.

It can be done, but it is quite irritating with the way that canonical have made snap a dependency in the minimal meta package. (And minimal on Ubuntu is really really super minimal, doesn't even have ping. Well apart from snap anyway).

They really went out of their way to make it awkward and annoying to take snap out.

But why bother running Ubuntu at all just to jump through hoops to avoid snaps? Snaps are obviously Ubuntus the thing, so feels counterproductive to run Ubuntu and fight against it.

use debootstrap to install instead, chroot is your friend. It comes with nothing and I mean that literally while still having the superior ubuntu kernel.

The frustrating part is that Snap's confinement story was supposed to be a selling point. Here we are with a priv-esc in the daemon itself. At this point I've just disabled snapd on all our Ubuntu boxes and moved to flatpak or building from source. The attack surface of a privileged install daemon that parses arbitrary package manifests is just too broad.

Why does snap-confine need to be setuid, rather than use a user namespace?

Snap supports programs running as real root. Would those work with user namespaces?

[dead]

When will these distros accept suid was a mistake and disable it. It has lead to critical local privilege escalation exploits so many times.

Probably never for package based distros. I could see it happening for image based distros, where systemd is slowly but surely providing all the building blocks for. It has had the option for `NoNewPrivileges=` in the `system.conf` since v239, so it isn't exactly difficult to disable for the entire system.

Though you'd be surprised how many binaries are suid binaries while they probably shouldn't be (passwd, mount, groupmems, ...), though alot can also work without being suid just more resticted in what they can do.

Around 20 years after suid is deprecated.

> When will these distros accept suid was a mistake and disable it.

I have the following C program that I use as an unprivileged user to put my system into and out of Game Mode.

1) Do you believe that this program is unsafe when compiled and set suid root?

2) How do you propose that I replace it with something that isn't suid root?

  #include <string.h>
  #include <stdlib.h>
  #include <stdio.h>
  #include <unistd.h>
  
  void maybe_do(const char * cmd) {
    if(system(cmd)) {
      perror(cmd);
      exit(2);
    }
  }
  
  int main(int argc, char** argv) {
    if(argc != 2) {
      return 1;
    }
    int turnOff = strncmp("on", argv[1], 2);
  
    if(setuid(0)) {
      perror("uid");
      return 2;
    }
    if(turnOff) {
      maybe_do("/usr/bin/cpupower frequency-set --governor schedutil > /dev/null");
      maybe_do("/bin/echo auto > /sys/class/drm/card0/device/power_dpm_force_performance_level");
    } else {
      maybe_do("/usr/bin/cpupower frequency-set --governor performance > /dev/null");
      maybe_do("/bin/echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level");
    }
    return 0;
  }

Run the part that needs root as a daemon, some server that accepts http requests

Use sudo and allow anyone to run the binary without password auth

Use the existing gamemode package

Those are a few options, of course it's your system in the end

Well, fuck snaps, that is.

Even though I've used ubuntu since 6.04, fuck snaps. I'm still stuck on Ubuntu even after 20 years. But fuck snaps.

Why are you stuck on Ubuntu, what is holding you back?

surprised this isn't talked about more

good read. thanks for sharing

surprised this isn't talked about more

Eh. Definitely not great but until they make it so you can't trivially MitM sudo, I don't think any local privilege execution bugs on Linux are especially notable, at least for most desktop users. Also there's the whole xkcd "at least they can't install drivers" thing.

[dead]

[flagged]