oss-security - Re: bubblewrap LPE

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

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

Message-ID: <20161013101019.uiaqlniqatzmc6j4@perpetual.pseudorandom.co.uk>
Date: Thu, 13 Oct 2016 11:10:19 +0100
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: bubblewrap LPE

On Wed, 12 Oct 2016 at 15:12:47 +0200, Sebastian Krahmer wrote:
> /usr/bin/bwrap may be installed mode 04755 or with cap_sys_admin and other
> file caps. I dont know if there are any dists already shipping it that way,
> but the Makefile and some RedHat spec files contain file caps for it.

It needs to be setuid root (or CAP_SYS_ADMIN, which might as well be setuid
root) to be useful on any distribution whose kernel doesn't normally allow
unprivileged users to open user-namespaces; in particular, Debian, RHEL,
and backports to older/LTS Ubuntu (but not current Ubuntu).

> For some reason it sets the PR_SET_DUMPABLE flag, as seen below. The comment about
> it looks strange to me. If thats really true, suid programs shouldn't
> be forced to play with the dumpable flag to achieve their goal.

I assume the developers of Bubblewrap wouldn't have done this if the
kernel (or at least *a* kernel they care about) didn't require it.
But hopefully becoming dumpable can be restricted to smaller sections
of the code.

If it's only for write_uid_gid_map(), then one way would be for that
function to fork(), with the child making itself dumpable and writing
the map files, and the parent just waiting for the child?

> Once the dumpable flag is set, there is a chance we could attach to the process,
> once the remaining caps are dropped and the whole process runs as user.

I have reported this to
<https://github.com/projectatomic/bubblewrap/issues/107>.

I believe the intention is that none of the operations that can pass over
the privilege separation socket are problematic, because they only affect
the sandboxed processes, and if you can ptrace bwrap then you can certainly
ptrace and subvert the sandboxed processes too. SETUP_SET_HOSTNAME clearly
doesn't match that intention, *if* Bubblewrap didn't unshare the UTS namespace
beforehand; Bubblewrap does insist that --hostname can't be used without
--unshare-uts, but you're right that a user outside the sandbox can ptrace
it and bypass that check by making it behave as though --hostname had been
used.

As a quick temporary fix for Debian, I'm reverting the addition of
SETUP_SET_HOSTNAME.

Am I right in thinking that this pseudocode would fix it while reinstating
the feature?

    case PRIV_SEP_OP_SET_HOSTNAME:
      if (!opt_unshare_uts)
        die_with_error ("Refusing to set hostname in original namespace");
      else if (!sethostname (... as before))
        die_with_error (... as before);

Thanks,
    S

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.