Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root

blog.qualys.com

Post reply on HN
Print view View original

101–110 of 131 posts

Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root

#101

Post by guenthert »

yjftsjthsd-h wrote: post #8
bangaladore wrote: post #6

Earlier quoted context omitted.

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..…

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…

> But… why?

> Performance is a frequently cited rationale for “Rewrite it in Rust” projects.

Rewrite from what? Python/Perl? If the original code is in C there _might_ be a performance gain (particularly if it was poorly written to begin with), but I wouldn't expect wonders.

Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root

#102

Post by c-hendricks »

simoncion wrote: post #82
c-hendricks wrote: post #66

Earlier quoted context omitted.

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

First off, thanks very much for giving me exactly what I asked for. You propose that instead of sometimes running ~five lines of C as root, I do one of the following: 1) Run a persistent whole-ass daemon using something for IPC... maybe DBUS, maybe HTTP, and all the code that that pulls in. 2) Use a setuid root program [0] to run the entire program as root, rather than just the ~five lines that need root privs. 3) Us…

> it's all code running as root!

Yup! There's no way around that if in the end you need elevated privileges somewhere.

What the other options allow is to contain the blast radius. With the daemon you can control access via groups on the socket, and with sudo you can control access via sudoers.d

> and who knows how many lines of Python

There's no python in gamemode...

Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root

#103

Post by simoncion »

c-hendricks wrote: post #102
simoncion wrote: post #82

Earlier quoted context omitted.

First off, thanks very much for giving me exactly what I asked for. You propose that instead of sometimes running ~five lines of C as root, I do one of the following: 1) Run a persistent whole-ass daemon using something for IPC... maybe DBUS, maybe HTTP, and all the code that that pulls in. 2) Use a setuid root program [0] to run the entire program as root, rather than just the ~five lines that need root privs. 3) Us…

> it's all code running as root! Yup! There's no way around that if in the end you need elevated privileges somewhere. What the other options allow is to contain the blast radius. With the daemon you can control access via groups on the socket, and with sudo you can control access via sudoers.d > and who knows how many lines of Python There's no python in gamemode...

> There's no python in gamemode...

...huh. There isn't. I checked out the git repo, and read the contents of the daemon directory. I guess I looked at the meson stuff at top level and thought to myself "Meson? Isn't that one of the half-billion Python build systems?" [0] and -from that thought- assumed that there was some Python in the directories I didn't examine. (It turns out that there is not. It's all C and configuration.)

> What the other options allow is to contain the blast radius.

I can do that by removing the "other" executable bit, adding the group executable bit, and setting the file's group appropriately to control access. You are limited to a single group, but it's not like you're unable to "contain the blast radius".

> With the daemon you can control access via groups on the socket...

As long as it's a UNIX socket, yes. (Getting guaranteed information about the identity of the process on the other side of such a socket is one of my favorite things about them.)

> Yup! There's no way around that if in the end you need elevated privileges somewhere.

Exactly. I hope the "setuid is evil and shouldn't exist" people who are complaining in good faith are capable of both realizing this and also recognizing that "just daemonize it" and "just run it with sudo" are -at times- not obviously the right thing to do.

[0] It's not!

Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root

#104

Post by simoncion »

magicalhippo wrote: post #89
simoncion wrote: post #82

Earlier quoted context omitted.

First off, thanks very much for giving me exactly what I asked for. You propose that instead of sometimes running ~five lines of C as root, I do one of the following: 1) Run a persistent whole-ass daemon using something for IPC... maybe DBUS, maybe HTTP, and all the code that that pulls in. 2) Use a setuid root program [0] to run the entire program as root, rather than just the ~five lines that need root privs. 3) Us…

> 1) Run a persistent whole-ass daemon using something for IPC This is the recommended way on Windows as well. Have the (privileged) installer install a privileged service, and have the non-privileged user program communicate with it.

> This is the recommended way on Windows as well.

Quite possibly because there are something like two people on earth who understand the Impersonation machinery [0] and one of the two is likely to cause an HN Black Banner Event any day now... so there's no real 'sudo' or 'setuid' equivalent on NT. ;)

[0] Seriously, it's fucking complicated. Decades ago, I wanted to write a sudo for the then-$DAYJOB. I gave up after a week when I couldn't even get the Impersonation equivalent of "Hello world" to work.

Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root

#106

Post by staticassertion »

TZubiri wrote: post #97
stevenhuang wrote: post #75

Earlier quoted context omitted.

> based on ignorance and naivety. About as nuanced as your bait framing of what a mere language ought/can do. Oh you're a python backend developer, guess that explains it.

So I was saying that rust monolithicism is NOT based on ignorance and naivety. Do you see what I mean by nuance? I think you just glanced at the comment, saw that there were negative words around rust, and you lossy compressed into "Rust bad".

Your post is very badly written. It's confusing and starts off with a totally weird comment about wasting revolutionary capacity. Expect downvotes.

Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root

#107

Post by Jnr »

sigmoid10 wrote: post #92
Sander_Marechal wrote: post #87

Earlier quoted context omitted.

I second Debian. All the good bits of Ubuntu have long since been ported back to Debian, and it has much more timely releases now.

Me too. Switching my home system from Ubuntu back to Debian was influenced a lot by snap. I don't get how they could fumble that one so hard. It goes against everything they used to stand for. If I want a bloated, slow, closed-source, proprietary app store with unclear security ramifications, I'll install MacOS or Windows. It also feels like app developers at least care a little bit about those stores. Mozilla for ex…

Yes, Debian is great.

But there is also Arch by the way :)

Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root

#108

Post by IshKebab »

yjftsjthsd-h wrote: post #71
someothherguyy wrote: post #57

Earlier quoted context omitted.

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

Could be. The thing is, it kinda doesn't matter; what matters is, what will result in the least bugs/vulnerabilities now? To which I argue the answer is, keeping GNU coreutils. I don't care that they have a head start, I care that they're ahead.

That's short sighted. The least number of bugs now isn't the only thing that matters. What about in 5 years from now? 10 years? That matters too.

To me it seems inarguable that eventually uutils will have fewer bugs than coreutils, and also making uutils the default will clearly accelerate that. So I don't think it's so easy to dismiss.

I think they were probably still a little premature, but not by much. I'd probably have waited one more release.

Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root

#109

Post by lathiat »

AgentME wrote: post #25
SoftTalker wrote: post #19

Earlier quoted context omitted.

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.

Only if you reuse the same random name. Which would be silly.

Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root

#110

Post by mynameajeff »

rglover wrote: post #11

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

We have notifications set up at my job for criticals and I quickly have learned how many 10.0 CVE's are related to random IoT devices that I can't even find via google.
Post reply on HN