Local root vulnerability in snap-confine
Successful exploitation of this vulnerability allows any unprivileged user to gain root privileges on the vulnerable host". Affected systems with untrusted users should probably be upgraded forthwith.
Posted Feb 17, 2022 20:06 UTC (Thu)
by jra (subscriber, #55261)
[Link] (41 responses)
https://www.qualys.com/2022/02/17/cve-2021-44731/oh-snap-...
"Discovering and exploiting a vulnerability in snap-confine has been
But that wasn't enough (it never is). Symlinks to the rescue for the malware community !
More evidence (if such were needed) that it is *IMPOSSIBLE* for even security engineers to write symlink-safe code (I sometimes wake up in a cold sweat thinking I missed something in the Samba symlink fixes. Worst of all, I probably did). When will our engineering community finally have enough of this and work to excise symlinks from our file systems ?
Posted Feb 17, 2022 20:15 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
IMO, it's POSIX API that we should stop deifying. It's a mess that evolved without much coherent thought.
Posted Feb 17, 2022 20:21 UTC (Thu)
by jra (subscriber, #55261)
[Link] (4 responses)
Symlinks are the most common security problem with Linux applications. I agree the POSIX filesystem API is a horrible mess, but it's symlinks that have made it so. The worst part of it is that what you're calling the "POSIX API" is actually the thin layer on top of the Linux system call interface (which because of symlinks is also a horrible mess).
Banning symlinks would remove a large number (I did the stats for my SambaXP talk) of security holes in applications on Linux. Think of the ones we've yet to find.
Posted Feb 17, 2022 20:28 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Any way that can mutate the filesystem structure causes exactly the same problem, and this most definitely includes mounts/overlays. And overlays are becoming critical for containers that we would want to launch without admin permissions.
So mutability of the filesystem is not going away and apps will have to deal with it, symlinks or not.
> I agree the POSIX filesystem API is a horrible mess, but it's symlinks that have made it so.
Posted Feb 18, 2022 20:41 UTC (Fri)
by developer122 (guest, #152928)
[Link]
Posted Feb 18, 2022 0:55 UTC (Fri)
by Karellen (subscriber, #67644)
[Link]
That feels backwards to me.
Posted Feb 18, 2022 1:15 UTC (Fri)
by aabc (subscriber, #55202)
[Link]
Posted Feb 18, 2022 8:22 UTC (Fri)
by mfuzzey (subscriber, #57966)
[Link] (4 responses)
Removing them in the name of security would be like unplugging the network cable to fix network security issues.
Maybe the API could be improved by phasing out the path based interface over the fd based interface but given the quantity of code using it that would be hard.
I don't think removing features or even *forcing* code changes in the name of security is a good idea. By all means we should provide more secure ways of doing things but security is not the top requirement in all use cases. By "forcing" above I mean things like changing the kernel so the old insecure app wouldn't work anymore (which isn't going to fly with Linus anyway)..
Posted Feb 18, 2022 8:50 UTC (Fri)
by taladar (subscriber, #68407)
[Link]
Posted Feb 18, 2022 18:21 UTC (Fri)
by jra (subscriber, #55261)
[Link] (2 responses)
Then applications can state:
"This application is only known to be secure when used on a filesystem mounted with the MNT_NOSYMFOLLOW option. Use on filesystems allowing symlinks can lead to race conditions and security vulnerabilities."
Let admins know how to protect themselves from this misfeature.
Posted Feb 19, 2022 6:23 UTC (Sat)
by intelfx (subscriber, #130118)
[Link] (1 responses)
I wouldn't use such software.
Posted Feb 19, 2022 23:21 UTC (Sat)
by jra (subscriber, #55261)
[Link]
I'm sick of symlink insanity.
Posted Feb 18, 2022 8:59 UTC (Fri)
by epa (subscriber, #39769)
[Link] (6 responses)
The legitimate uses of symlinks are mostly static -- a shared library linked to a different name, an old user who no longer exists. They don't change much. Can we somehow restrict the times at which symbolic links can be created or changed? Perhaps a process should only be able to see the symlinks that existed when that process started, unless it calls a refresh_symlinks() system call. That would avoid path traversal race conditions while still letting us have the uses of symlinks we've come to depend on.
Posted Feb 18, 2022 11:51 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (4 responses)
Other questions that come to mind:
- Should symlinks in mounts that show up after the process starts count?
Sure, global mutable state is terrible in practice and a fun source of bugs for everyone, but that's what a filesystem *is*, so I don't see how snapshotting it makes it any better without a way to launch a process that is pinned to "the symlink view of PID X" for a way to have some sanity in multi-process systems or debugging scenarios.
Posted Feb 18, 2022 12:46 UTC (Fri)
by epa (subscriber, #39769)
[Link] (3 responses)
It would have to be based on real world time, not just whatever mtime is in the file system. A fully snapshottable filesystem would be impossible to graft on to current POSIX semantics, but if we're just making a sticking plaster for race conditions with symlinks, some kind of per-process view of the world seems possible. You're not trying to snapshot exactly what symlinks existed at a point of time, but only to note whether one has changed in any way, and if so fail when it's used.
Posted Feb 18, 2022 14:57 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (1 responses)
Cheers,
Posted Feb 18, 2022 20:50 UTC (Fri)
by developer122 (guest, #152928)
[Link]
Posted Feb 18, 2022 17:43 UTC (Fri)
by nix (subscriber, #2304)
[Link]
What? It would cause new failures for older code, i.e. it would introduce countless DoS vectors, only a microscopic proportion of which correspond to actual attacks, but all of which would annoy users (where "annoy users" spans the entire spectrum from "slightly annoying" through "bug we can't track down that goes away on restarting" through to "oops now the system is unbootable because of an unexpected and undiagnosed EREFRESH while installing something boot-critical").
Hell no.
Posted Feb 21, 2022 10:14 UTC (Mon)
by kronat (subscriber, #117266)
[Link]
Posted Feb 18, 2022 11:48 UTC (Fri)
by auerswal (subscriber, #119876)
[Link] (2 responses)
Please read the report, there are no symlink vulnerabilities mentioned at all.
Posted Feb 18, 2022 12:49 UTC (Fri)
by epa (subscriber, #39769)
[Link] (1 responses)
Posted Feb 19, 2022 18:02 UTC (Sat)
by spigot (subscriber, #50709)
[Link]
Posted Feb 18, 2022 15:35 UTC (Fri)
by intgr (subscriber, #39733)
[Link] (19 responses)
Thanks for the link, this report is pure gold and worth reading in full.
Truly, props to snap-confine developers for implementing mitigations to make exploitation so complicated.
As for the other vulnerabilities they found......... *sigh*
> CVE-2021-3995: Unauthorized unmount in util-linux's libmount
> only the first "sz" characters of the
This is hilarious and sad at the same time. It would be obvious to blame the C language. But I think it's time to start putting blame on developers as well, when instead of using proper primitives like "compare string A and B and tell me if they're equal", they insist on using low-level primitives with pointer arithmetic and buffer manipulation. This is the same mindset that led to the recent "pkexec" vulnerability.
This way of parsing and handling strings should be unacceptable in a culture that values security. Please use (create) a proper C library of high-level string manipulation functions, no shortcuts!
> CVE-2021-3996: Unauthorized unmount in util-linux's libmount
> when parsing /proc/self/mountinfo, the libmount blindly
> For example, on Fedora, /tmp is a tmpfs, so we can mount a basic FUSE
Hilarious. This, again, is a culture problem. We should be migrating to proper serialization formats when communicating complex data structures to between kernel and userland, instead of this stringly typed complex to parse hodgepodge that is "mountinfo".
The "deleted" flag should be a boolean or flags field, not part of the path name string.
> CVE-2021-3997: Uncontrolled recursion in systemd's systemd-tmpfiles
> if we create thousands
> - for example, on Ubuntu 21.04, systemd-tmpfiles fails to create the
Mind=blown. One would expect the crash of a startup service to "fail safe" and possibly disable part of the system. But the auditors managed to turn it into a privilege escalation vulnerability.
Not sure where to put the blame, I could see myself making this mistake just as well.
Posted Feb 18, 2022 16:20 UTC (Fri)
by epa (subscriber, #39769)
[Link] (12 responses)
You can also blame whoever came up with the mountinfo format, but that may be a little unfair as I'm sure it has simply evolved rather than being designed. With hindsight, if you are pasting together strings in a formatted text output you should think in advance of what to do if one of the formatting characters (like, I don't know, newline) appears in a string. But again, there's no cultural consensus on what to do, and any scheme you invented would probably be parsed wrongly by lots of userland code, since it's an uncommon case.
Posted Feb 18, 2022 18:33 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link] (2 responses)
Posted Feb 18, 2022 21:11 UTC (Fri)
by ms-tg (subscriber, #89231)
[Link] (1 responses)
I wonder if there are steps that, over some years, could help make the unknown number of people visible? For example, what if Linux, either in the file systems or more likely in distro-level utilities, simply detected filenames that violated certain rules, and let the user know that these existed and might need to be renamed to follow a proposed RFC naming convention in the future if it becomes accepted?
Perhaps users could opt-in to also reporting counts back to a central server?
I'm even picturing a nice web page, the way big security vulnerabilities have these days? Maybe 'linux-filenames-rfc.io'? Which could include the latest text of the proposal, links to Github where changes can be proposed, mailing lists where it is discussed, etc?
Using these sorts of community consensus approaches, might it be possible to get more of a defined sense of how often how big a real-world impact would be felt by any proposed reduction in Linux filename permissiveness?
Posted Feb 24, 2022 11:07 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
Sure, all hell could then break loose, as old apps assume they can write garbage, etc etc, but it gives *developers* the opportunity to have a flag day and clean up their own stuff. Then they recommend that users enable this flag, which can't be enabled on existing systems to avoid breaking them, and all this goodness is enforced going forwards.
Then you reverse the default state of the flag so all of a sudden, people with old apps have to ask for the old behaviour ... But the breakage is minimised by making it easy for those in the know to be early adopters and test their own systems. You only need something like SUSE's Open Build System flipping their default setting, as developer's build systems start breaking and a distro could then rapidly switch their own default knowing all the apps they've built are compliant ...
Cheers,
Posted Feb 19, 2022 9:40 UTC (Sat)
by adobriyan (subscriber, #30858)
[Link]
Posted Feb 19, 2022 10:26 UTC (Sat)
by intgr (subscriber, #39733)
[Link]
I don't really blame whoever came up with it, but I blame kernel developers for not offering better alternatives for new use cases and migrating old kludges over.
Kernel developers should decide on a new unambiguous and extensible serialization format for complex nested data structures. In 1990s these lessons hadn't really been learned yet, but in 2022 we have protobuf, Avro, Arrow, ASN.1, JSON and plenty more. I'm sure we can find at least one that suits the kernel use case.
> blame whoever decided that ( ) and space should be legal characters in a mount point path name
This wouldn't even help that much. Restricting characters in path names would solve this particular issue for paths, but there are still plenty of other strings with arbitrary content that may end up being communicated to user space. So would you propose blocking a set of characters in *all* kernel inputs?
I feel like a broken record at this point, but again: if you're having trouble transmitting certain characters in your serialization format, it's the serialization format that sucks.
Posted Feb 20, 2022 3:03 UTC (Sun)
by foom (subscriber, #14868)
[Link] (6 responses)
If there's blame to be had, it'd be for the Unix shell language which treats strings in a variable unsafely by default!
Posted Feb 21, 2022 7:01 UTC (Mon)
by epa (subscriber, #39769)
[Link] (5 responses)
On some platforms space is not a legal character in filenames but you can use non-breaking space, which isn’t treated specially by the shell. I’m not sure whether that is better or worse.
Posted Feb 21, 2022 12:43 UTC (Mon)
by zdzichu (subscriber, #17118)
[Link] (4 responses)
Posted Feb 21, 2022 13:37 UTC (Mon)
by adobriyan (subscriber, #30858)
[Link] (3 responses)
'-' is allowed in URLs. Any site issuing randomised names (like: YT) to user submitted content will create a file starting with minus easily.
Posted Feb 21, 2022 14:15 UTC (Mon)
by zdzichu (subscriber, #17118)
[Link] (2 responses)
Posted Feb 21, 2022 17:33 UTC (Mon)
by adobriyan (subscriber, #30858)
[Link] (1 responses)
GNU ls(1) started to quote filenames with spaces at some point, it was huge step in right direction because copy paste suddenly started working "out of the box". More features lke this are necessary.
Posted Feb 21, 2022 18:04 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Just add automatic escaping for such names.
Posted Feb 19, 2022 8:55 UTC (Sat)
by roc (subscriber, #30627)
[Link] (3 responses)
The problem is that C doesn't provide enough language features to make a library string type as convenient and performant to use as char*. (Language features such as destructors.) Therefore C programmers will be disinclined to use it. It's not an accident that after all these years no such library is in broad use.
Posted Feb 20, 2022 16:59 UTC (Sun)
by epa (subscriber, #39769)
[Link]
Posted Feb 21, 2022 15:20 UTC (Mon)
by rgmoore (✭ supporter ✭, #75)
[Link] (1 responses)
I think your comment gets very nicely at the root of our problems. We will never get security right as long as it is given lower priority than convenience and performance.
Posted Feb 22, 2022 2:29 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
As for convenience, sure it's handy to be able to pass a "string" around in a register because it's "just" the size of a pointer, but weighing that against the inconvenience of having to debug mishandling of these APIs, they are by *far* in the red in my book. I mean, we have how many flavors of "append a string"? `strcat`, `strncat`, and `strlcat`? Toss `snprintf` in there too if you want to be fancy. And there's not even *consensus* on this set. Reviewing code dense with use of the C string library requires notes because I need to track where lengths are coming from, are the right APIs being used, and "oh, that's just a poorly coded `strdup`" recognitions. I don't find it useful.
So given that it scores (IMO) a 2/5 on performance (sure, registers get you something I guess), 1/5 in (overall) convenience, and 0/5 on security because the APIs just don't help out half the time, why, specifically, would roc's "attitude" not be warranted?
Posted Feb 20, 2022 23:42 UTC (Sun)
by judas_iscariote (guest, #47386)
[Link] (1 responses)
What is actually wanted is system calls, that return unambigous, well defined data.. same on all archictectures or kernel config options.. no new proc files to parse or to write to...
Posted Feb 21, 2022 16:37 UTC (Mon)
by nybble41 (subscriber, #55106)
[Link]
We have the system calls (open, read, write). What is missing is the "unambiguous, well-defined data". Given an appropriate serialization format there is nothing wrong with communicating the data through /proc. I see no need to restrict access to languages with support for making special-purpose system calls.
Posted Feb 18, 2022 21:06 UTC (Fri)
by Smon (guest, #104795)
[Link] (5 responses)
Posted Feb 18, 2022 21:57 UTC (Fri)
by walters (subscriber, #7396)
[Link] (1 responses)
Posted Feb 20, 2022 12:54 UTC (Sun)
by smcv (subscriber, #53363)
[Link]
The sandboxing layer of Flatpak *usually* (on modern distros) runs with the privileges of its caller, and can't do anything its caller couldn't already do on their own.
The exception to that is when the distro doesn't allow unprivileged users to create new user namespaces, for example Debian 10 and RHEL 7, in which case the bubblewrap executable (typically /usr/bin/bwrap or /usr/libexec/flatpak-bwrap) needs to be setuid root. I don't think it's coincidence that two out of four CVEs reported against bubblewrap have only been applicable when it's setuid root, and those two were the really serious ones. Setuid is dangerous and it's good to avoid it whenever possible (see also the recent pkexec vulnerability).
(CVE-2016-8659 and CVE-2020-5291 were root privilege escalation when setuid root, but were not applicable when not setuid root; CVE-2017-5226 wasn't really a vulnerability in bubblewrap at all, but more like a vulnerability in Flatpak and other bubblewrap users; CVE-2019-12439 only applied in unusual system configurations, and as far as I'm aware it was only a denial-of-service.)
Posted Feb 20, 2022 12:38 UTC (Sun)
by smcv (subscriber, #53363)
[Link] (2 responses)
In particular, when Flatpak developers encounter something that would be hard to implement securely, we are often able to declare it to be out-of-scope and not implement it at all, resulting in fewer attack vectors.
Flatpak is designed to sandbox "apps", with a meaning that is not 100% well-defined, but "programs that behave like an Android/iOS app" or "GUI programs with a .desktop file" are reasonable approximations. Snap is designed to sandbox "apps", but also non-"app" things like system services: you can install lxd as a Snap, but it would not be possible to install lxd as a Flatpak app.
I personally think that's a strength of Flatpak rather than a weakness, but it would be reasonable for Snap users/developers to disagree on that: neither approach is trivially better than the other.
Posted Feb 20, 2022 13:11 UTC (Sun)
by smcv (subscriber, #53363)
[Link] (1 responses)
As with the different scopes I described in my previous comment, this is a trade-off, and neither is trivially better than the other.
The fact that Snap uses AppArmor means it can rely on the LSM mechanism in the kernel, which is quite powerful, particularly if you are willing to patch the kernel (I believe Ubuntu's kernel patches to add SO_PEERSEC support to AppArmor still haven't gone upstream). If the kernel gives you information about a peer's LSM labels, then you can trust that information to be correct and securely obtained; and if a process is restricted by LSM policies, the kernel will forbid anything that those policies forbid, without needing to rely on other mechanisms like userns and seccomp as heavily as Flatpak does.
On the other hand, you need CAP_MAC_ADMIN (i.e. root) to manipulate AppArmor profiles, and if running on a distribution like Fedora that uses a different "big" LSM, or a distribution that doesn't compile any of the "big" LSMs into its kernel at all, then you're not going to be able to benefit from AppArmor at all.
Flatpak has gone for the approach that makes it work equally well on "most" distros, and give it an equal level of sandboxing on "most" distros even if installed as non-root. Snap has gone for the approach that is maximally powerful on e.g. Ubuntu, at the cost of working less well on non-Ubuntu and requiring root.
Posted Feb 21, 2022 23:32 UTC (Mon)
by Smon (guest, #104795)
[Link]
Local root vulnerability in snap-confine
extremely challenging (especially in a default installation of Ubuntu),
because snap-confine uses a very defensive programming style, AppArmor
profiles, seccomp filters, mount namespaces, and two Go helper programs.
...
setup_private_mount() is programmed very defensively (f*() and *at() syscalls, O_DIRECTORY and O_NOFOLLOW flags) to avoid race conditions:"
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
But they're not!
Not really? It's mostly the lack of handle-based interfaces that is the issue, both for filesystem APIs and for the process/signals API.
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
The worst part of it is that what you're calling the "POSIX API" is actually the thin layer on top of the Linux system call interface
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Would it be fair to say that most of these security holes are not caused by symlinks alone, but by race conditions with symlinks?
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
- How would this work with something like AndrewFS where finding all symlinks sounds like an absolute nightmare?
- Can this be namespaced (i.e., "update symlink perms under `/etc/systemd/system`" for systemd)?
- Now the kernel is subject to symlink races that hide themselves in process-specific state that you can't see without a way to debug?
- If it is just `mtime`-based or whatever, that is trivially attacker-controlled too, so that doesn't sound like it's saving anything there.
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Wol
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
"owning" a symlink?
Based on the above, isn't it possible to "block" any modification to the symlink until the application(s) that "locked" the symlink by opening it for reading is (are) done (doing a close on it)?
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Amusingly, the Acknowledgments section of the write-up has this dedication:
Local root vulnerability in snap-confine
This advisory is dedicated to 8lgm -- followers of symbolic links,
overflowers of stack buffers, and dereferencers of NULL pointers: [...]
Local root vulnerability in snap-confine
> current user's uid are compared to the filesystem's "user_id" option (sz
> is user_id's length). This second vulnerability allows an unprivileged
> user to unmount the FUSE filesystems that belong to certain other users;
> for example, if our own uid is 1000, then we can unmount the FUSE
> filesystems of the users whose uid is 100, 10, or 1
> removes any " (deleted)" suffix from the mountpoint pathnames
> filesystem named "/tmp/ (deleted)" (with FUSE's "hello world" program,
> ./hello) and unmount /tmp itself (a denial of service)
> of nested directories in /tmp, then "systemd-tmpfiles --remove" (when
> executed as root at boot time) will call its rm_rf_children() function
> recursively (on each nested directory) and will exhaust its stack and crash
> directory /run/lock/subsys; but because /run/lock is world-writable,
> attackers can create their own /run/lock/subsys; and because various
> legacy packages and daemons write into /run/lock/subsys as root, the
> attackers may create arbitrary files via symlinks in /run/lock/subsys.
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Wol
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Everything except NULL and / is allowed in filenames. But it doesn't mean it's a good idea to use it. Please take time to read the essay, it is eye-opening.
Local root vulnerability in snap-confine
And you do not need a website. Just touch -- --foot-shooter
(or touch -- -rf\ .
if you like).
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Flatpaks bwrap is able to run as non root and use user-namespacing. So this cannot happen there.
Why does snap need a suid binary?
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine
Local root vulnerability in snap-confine