oss-security - Re: Mock, Snap, LXC expose(d) chroot, container trees with unsafe permissions and contents to host users, pose risk to host

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Tue, 16 Jan 2024 22:07:19 +0100
From: Willy Tarreau <w@....eu>
To: oss-security@...ts.openwall.com
Cc: Marco Benatto <mbenatto@...hat.com>, Pavel Raiskup <praiskup@...hat.com>,
        Zack Miele <zmiele@...hat.com>
Subject: Re: Mock, Snap, LXC expose(d) chroot, container trees
 with unsafe permissions and contents to host users, pose risk to host

Hi,

On Tue, Jan 16, 2024 at 09:37:24PM +0100, Solar Designer wrote:
> On Mon, Jan 08, 2024 at 10:47:31PM +0100, Vegard Nossum wrote:
> > here's an example of setuid-root binaries from snaps on an Ubuntu system:
> > 
> > $ ls -l $(find /snap/ -type f -executable -perm -4000 -name su 2>/dev/null)
> > -rwsr-xr-x 1 root root 44664 nov.  29  2022 /snap/core18/2796/bin/su
> > -rwsr-xr-x 1 root root 44664 nov.  29  2022 /snap/core18/2812/bin/su
> > -rwsr-xr-x 1 root root 67816 mai   30  2023 /snap/core20/2015/usr/bin/su
> > -rwsr-xr-x 1 root root 67816 mai   30  2023 /snap/core20/2105/usr/bin/su
> > -rwsr-xr-x 1 root root 55672 f??vr. 21  2022 /snap/core22/1033/usr/bin/su
> > -rwsr-xr-x 1 root root 55672 f??vr. 21  2022 /snap/core22/864/usr/bin/su
> > 
> > (I count 64 such binaries on this particular system when not restricting
> > to "su" -- if there are older versions, as indeed there seems to be at a
> > glance, it's not unthinkable to find something buggy there that maybe
> > shouldn't be runnable.)

I mentioned this to various people in the past already, being shocked to
find 4 *different* versions of sudo in snap subdirs and rootfs. IMHO,
surely if there are 4 versions, at least 3 of them were considered to
have at least one flaw, yet are still present. That the good old well
known issue with chroots that tend to age without anybody caring about
them, except that they're full of interesting stuff :-/

I don't know what are the rules that govern updates of such directories
as I don't understand how the mechanism works, but I find that is does
significantly increase the attack surface and it reminds two decades
ago when I was regularly reminding users to be extremely cautious about
chroots :-/

> > I could be completely wrong, I haven't looked into it. At a glance, many
> > of these binaries will not run directly because they are trying to load
> > older versions of shared libraries that don't exist in the default
> > search paths.
>
> That's a very good point about incompatible shared libraries - things
> can be much worse if the libraries do exist, but are just sufficiently
> different to expose or create a vulnerability - potentially one that
> didn't exist with binary+libraries versions in either the chroot or the
> host system on its own.

That's not always the case regarding libs. Just an example right now
on just a local machine:

  $ ls -l /snap/core*/current/usr/bin/mount
  -rwsr-xr-x 1 root root 55528 May 30  2023 /snap/core20/current/usr/bin/mount
  -rwsr-xr-x 1 root root 47480 Feb 21  2022 /snap/core22/current/usr/bin/mount
  $ /snap/core20/current/usr/bin/mount --version
  mount from util-linux 2.34 (libmount 2.37.2: selinux, smack, btrfs, verity, namespaces, assert, debug)
  $ /snap/core22/current/usr/bin/mount --version
  mount from util-linux 2.37.2 (libmount 2.37.2: selinux, smack, btrfs, verity, namespaces, assert, debug)

Here there's only one install per major version so the impact is more
limited, however both are clearly executable. and if one of them is
vulnerable, I don't know since I didn't expect to find setuids all over
the machine. For me it's almost always a fault to put a setuid inside a
chroot, as it suggests you'll need to let untrusted users run some
privileged commands and there's something a bit fishy in doing this,
it's a bit like telling your kids "we're out this evening, you can
invite your friends but only those you trust, have a nice evening".

The machine where I had 4 different versions was a lab machine shared
with multiple users, which has long been decomissioned, so I don't even
know how those were supposed to be maintained in parallel or updated
or whatever, but that looked a bit gross to me.

I continue to find this mechanism concerning and I try hard to completely
remove it from machines I set up because I feel like it can leave open
holes in my back for stuff I didn't ask for and don't understand. I've
heard that the mechanism might be going to be enforced a bit more on
users in future versions, I don't know if that's true but if so I find
it a bit scary to multiply setuid exposure like this.

Just my two cents,
Willy

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.