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.
When will these distros accept suid was a mistake and disable it. It has lead to critical local privilege escalation exploits so many times.
ifh-hn 2 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?
dogleash 2 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 50 minutes ago [-]
The mistake seems to be using a predictable path (/tmp/.snap) in a publicly-writable directory.
pbhjpbhj 1 minutes 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?}
cyberpunk 2 hours ago [-]
[flagged]
dgxyz 47 minutes ago [-]
Rewrite tools in new language, get new exciting bugs!
delamon 2 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 2 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]
> 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.
Rendered at 20:00:26 GMT+0000 (Coordinated Universal Time) with Vercel.
The article linked in the submission is more verbose but less clear and half of it is an advertisement for their product.
Edit: for others who may be curious https://www.cve.org/Downloads
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?}
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.