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.
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?
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.
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.
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 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.
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.
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.
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.
This.
Might be worth updating the link.
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.
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?
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.
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.
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.
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.
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.
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
When will these distros accept suid was a mistake and disable it. It has lead to critical local privilege escalation exploits so many times.
Around 20 years after suid is deprecated.