The article linked in the submission is more verbose but less clear and half of it is an advertisement for their product.
NooneAtAll3 43 minutes ago [-]
I love that cheeky "oh btw, there's also another vulnerability in rust coreutils rewrite, but we aren't talking about that" paragraph
cadamsdotcom 2 hours ago [-]
This.
Might be worth updating the link.
AgentME 23 minutes ago [-]
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/), but it's stored in memory only, mainly intended for unix sockets it seems.
thayne 7 minutes ago [-]
> 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.
ifh-hn 3 hours ago [-]
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?
AgentME 1 hours ago [-]
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.
akdor1154 1 hours ago [-]
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.
dogleash 3 hours ago [-]
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.
SoftTalker 3 hours ago [-]
The mistake seems to be using a predictable path (/tmp/.snap) in a publicly-writable directory.
pbhjpbhj 2 hours ago [-]
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?}
wahern 33 minutes ago [-]
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.
SoftTalker 1 hours ago [-]
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.
AgentME 31 minutes ago [-]
If the directory had a random name, the attacker could see that name and recreate it after /tmp is flushed.
sysops9x 57 minutes ago [-]
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.
capitainenemo 2 hours ago [-]
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.
gertrunde 21 minutes ago [-]
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.
himata4113 56 minutes ago [-]
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.
rglover 2 hours ago [-]
Semi-related: does anybody know of a reliable API that announces CVEs as they're published?
Even though I've used ubuntu since 6.04, fuck snaps. I'm still stuck on Ubuntu even after 20 years. But fuck snaps.
Neskenfrederi44 36 minutes ago [-]
surprised this isn't talked about more
charcircuit 2 hours ago [-]
When will these distros accept suid was a mistake and disable it. It has lead to critical local privilege escalation exploits so many times.
wmf 1 hours ago [-]
Around 20 years after suid is deprecated.
goatyishere25 9 minutes ago [-]
the comments here are better than the article lol
cyberpunk 4 hours ago [-]
[flagged]
dgxyz 2 hours ago [-]
Rewrite tools in new language, get new exciting bugs!
delamon 3 hours ago [-]
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
bangaladore 3 hours ago [-]
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]
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.
> 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.
The article linked in the submission is more verbose but less clear and half of it is an advertisement for their product.
Might be worth updating the link.
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/), but it's stored in memory only, mainly intended for unix sockets it seems.
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.
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 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.
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?}
They really went out of their way to make it awkward and annoying to take snap out.
Edit: for others who may be curious https://www.cve.org/Downloads
Even though I've used ubuntu since 6.04, fuck snaps. I'm still stuck on Ubuntu even after 20 years. But fuck snaps.
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...
> 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.