[HN Gopher] CVE-2026-3888: Important Snap Flaw Enables Local Pri...
___________________________________________________________________
CVE-2026-3888: Important Snap Flaw Enables Local Privilege
Escalation to Root
Author : askl
Score : 72 points
Date : 2026-03-18 15:43 UTC (7 hours ago)
(HTM) web link (blog.qualys.com)
(TXT) w3m dump (blog.qualys.com)
| cyberpunk wrote:
| > 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!
| delamon wrote:
| 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 wrote:
| 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...
| yjftsjthsd-h wrote:
| 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.
| staticassertion wrote:
| 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.
| dgxyz wrote:
| Rewrite tools in new language, get new exciting bugs!
| ptx wrote:
| 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.
| cadamsdotcom wrote:
| This.
|
| Might be worth updating the link.
| NooneAtAll3 wrote:
| I love that cheeky "oh btw, there's also another vulnerability
| in rust coreutils rewrite, but we aren't talking about that"
| paragraph
| cyberax wrote:
| 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.
| ifh-hn wrote:
| 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 wrote:
| 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 wrote:
| The mistake seems to be using a predictable path (/tmp/.snap)
| in a publicly-writable directory.
| pbhjpbhj wrote:
| 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?}
| SoftTalker wrote:
| 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 wrote:
| If the directory had a random name, the attacker could
| see that name and recreate it after /tmp is flushed.
| wahern wrote:
| 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.
| akdor1154 wrote:
| 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.
| AgentME wrote:
| 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.
| thayne wrote:
| 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.
| rglover wrote:
| 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
| charcircuit wrote:
| 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 wrote:
| Around 20 years after suid is deprecated.
| NekkoDroid wrote:
| 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.
| capitainenemo wrote:
| 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.
| himata4113 wrote:
| 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.
| gertrunde wrote:
| 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.
| sysops9x wrote:
| 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.
| Neskenfrederi44 wrote:
| surprised this isn't talked about more
| AgentME wrote:
| 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.
| thayne wrote:
| > 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.
| zokier wrote:
| which of course raises the question why the fuck snap doesn't
| use either of these mechanisms?
| NekkoDroid wrote:
| > 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.
| broadsidepicnic wrote:
| 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.
| thayne wrote:
| Why does snap-confine need to be setuid, rather than use a user
| namespace?
| curt15 wrote:
| Snap supports programs running as real root. Would those work
| with user namespaces?
| IshKebab wrote:
| 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.
| kev009 wrote:
| 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.
___________________________________________________________________
(page generated 2026-03-18 23:00 UTC)