CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root
61–70 of 131 posts
Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root
#62Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root
#63Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root
#64Earlier quoted context omitted.
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. {Wi…
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.
Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root
#65Better 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.
I love that cheeky "oh btw, there's also another vulnerability in rust coreutils rewrite, but we aren't talking about that" paragraph
Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root
#66When will these distros accept suid was a mistake and disable it. It has lead to critical local privilege escalation exploits so many times.
> When will these distros accept suid was a mistake and disable it. I have the following C program that I use as an unprivileged user to put my system into and out of Game Mode . 1) Do you believe that this program is unsafe when compiled and set suid root? 2) How do you propose that I replace it with something that isn't suid root? #include #include #include #include void maybe_do(const char * cmd) { if(system(cmd))…
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
Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root
#67[flagged]
0 benefits and only risks involved. Users are forced to choose between a worse new version or an older version that will no longer be supported. Like SystemD all over again.
It feels like there is a phenomenon where software devs (especially Open Source) have to keep developing even when just doing nothing would result in a better product. Like there's some monetization incentives to keep touching the thing so that you can get paid.
Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root
#68Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root
#69When will these distros accept suid was a mistake and disable it. It has lead to critical local privilege escalation exploits so many times.
> When will these distros accept suid was a mistake and disable it. I have the following C program that I use as an unprivileged user to put my system into and out of Game Mode . 1) Do you believe that this program is unsafe when compiled and set suid root? 2) How do you propose that I replace it with something that isn't suid root? #include #include #include #include void maybe_do(const char * cmd) { if(system(cmd))…
2) I suggest that a service is created for managing system performance that exposes an API to your user to turn on and off game mode.
Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root
#70Earlier quoted context omitted.
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
[flagged]