Summary: | <sys-apps/shadow-4.8-r3[pam] installs setuid binaries with permissive pam configuration allowing user/group management without authentication (CVE-2019-19882) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Michael Weiser <michael> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | base-system, joakim.tjernlund |
Priority: | Normal | Flags: | nattka:
sanity-check-
|
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://github.com/gentoo/gentoo/pull/14032 https://bugs.gentoo.org/show_bug.cgi?id=712372 https://bugs.gentoo.org/show_bug.cgi?id=894998 |
||
Whiteboard: | B2 [glsa+ cve] | ||
Package list: |
sys-apps/shadow-4.8-r4
|
Runtime testing required: | --- |
Description
Michael Weiser
2019-12-07 17:37:35 UTC
-pam also kills PAM support in /bin/su, /bin/passwd and /bin/login. :-/ An explicit use_enable seems the way to go: --- /usr/portage/sys-apps/shadow/files/pam.d-include/shadow 2015-08-09 02:38:18.000000000 +0200 +++ /usr/local/portage/sys-apps/shadow/files/pam.d-include/shadow 2019-12-07 18:59:56.920440259 +0100 @@ -1,7 +1,7 @@ #%PAM-1.0 auth sufficient pam_rootok.so -auth required pam_permit.so +auth required pam_deny.so account include system-auth diff -ur /usr/portage/sys-apps/shadow/shadow-4.8-r1.ebuild /usr/local/portage/sys-apps/shadow/shadow-4.8-r1.ebuild --- /usr/portage/sys-apps/shadow/shadow-4.8-r1.ebuild 2019-12-02 11:39:41.000000000 +0100 +++ /usr/local/portage/sys-apps/shadow/shadow-4.8-r1.ebuild 2019-12-07 18:59:43.413518749 +0100 @@ -12,7 +12,7 @@ LICENSE="BSD GPL-2" SLOT="0" KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~riscv ~s390 ~sh ~sparc ~x86" -IUSE="acl audit bcrypt +cracklib nls pam selinux skey split-usr +su xattr" +IUSE="acl audit bcrypt +cracklib nls pam selinux skey split-usr +su xattr account-tools-setuid" # Taken from the man/Makefile.am file. LANGS=( cs da de es fi fr hu id it ja ko pl pt_BR ru sv tr zh_CN zh_TW ) @@ -68,6 +68,7 @@ $(use_with skey) $(use_with su) $(use_with xattr attr) + $(use_enable account-tools-setuid) ) econf "${myeconfargs[@]}" Incidentally this not only disables setuid install of the binaries but PAM support in them while the other tools retain PAM support: $ ldd /bin/login /usr/sbin/useradd /bin/login: linux-vdso.so.1 (0x00007ffd217fe000) libpam.so.0 => /lib64/libpam.so.0 (0x00007f7bd6023000) libpam_misc.so.0 => /lib64/libpam_misc.so.0 (0x00007f7bd601e000) libc.so.6 => /lib64/libc.so.6 (0x00007f7bd5e4c000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f7bd5e46000) /lib64/ld-linux-x86-64.so.2 (0x00007f7bd607f000) /usr/sbin/useradd: linux-vdso.so.1 (0x00007ffd08b68000) libacl.so.1 => /lib64/libacl.so.1 (0x00007f19c6602000) libattr.so.1 => /lib64/libattr.so.1 (0x00007f19c65fa000) libc.so.6 => /lib64/libc.so.6 (0x00007f19c6428000) /lib64/ld-linux-x86-64.so.2 (0x00007f19c666d000) src/Makefile.am: if ACCT_TOOLS_SETUID suidusbins += chgpasswd chpasswd groupadd groupdel groupmod newusers useradd userdel usermod endif [...] if ACCT_TOOLS_SETUID LIBPAM_SUID = $(LIBPAM) else LIBPAM_SUID = endif src/useradd.c: #ifdef ACCT_TOOLS_SETUID #ifdef USE_PAM [...] if (PAM_SUCCESS == retval) { retval = pam_authenticate (pamh, 0); } if (PAM_SUCCESS == retval) { retval = pam_acct_mgmt (pamh, 0); } [...] (void) pam_end (pamh, retval); #endif /* USE_PAM */ #endif /* ACCT_TOOLS_SETUID */ So install of the pam configs could be omitted in that case as well. Would this change be a good mitigation? @@ -58,6 +59,7 @@ --enable-shared=no --enable-static=yes $(use_enable nls) + $(use_enable !pam account-tools-setuid) $(use_with acl) $(use_with audit) $(use_with bcrypt) Do I understand correctly, that it is intended to: a.) disable setuid account management tools if PAM support is enabled and b.) enable setuid account management tools if PAM support is disabled? What happens if someone wants c.) PAM support *and* setuid account management tools enabled? Also, if someone disabled PAM support, wouldn't that leave them with setuid root user management binaries and no authentication whatsoever, again opening up arbitrary user management by any user on the system? I guess, the binaries could be chgrp'd to some acctmgmt group and set to mode 1710 to gain some control of that. Configure --help reads: --enable-account-tools-setuid Install the user and group management tools setuid and authenticate the callers. This requires --with-pam. So I think, case b.) is not intended, supported nor tested. Actually, come to think of it and testing it, configure refuses that combination: ./configure --without-libpam --enable-account-tools-setuid checking for a BSD-compatible install... /usr/bin/install -c [...] checking use login and su access checking if PAM not used... yes configure: error: PAM support is required for --enable-account-tools-setuid So I think, $(use_enable !pam account-tools-setuid) would break building with -pam. Also, please don't forget that for case c.) (setuid + pam), the pam.d configs still need to be fixed not to leave user management open to anyone by default. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f569e6070dea96b746db27eb5586f7a73c99916d commit f569e6070dea96b746db27eb5586f7a73c99916d Author: Lars Wendler <polynomial-c@gentoo.org> AuthorDate: 2019-12-17 07:50:29 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2019-12-17 07:50:49 +0000 sys-apps/shadow: Revbump to no longer install binaries SUID-root Thanks-to: Michael Weiser <michael@weiser.dinsnail.net> Bug: https://bugs.gentoo.org/702252 Package-Manager: Portage-2.3.82, Repoman-2.3.20 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> sys-apps/shadow/{shadow-4.8-r1.ebuild => shadow-4.8-r2.ebuild} | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) To be honest, I don't see a compelling reason to install these binaries SUID-root. If someone wants to enable users to use these binaries, one can still create corresponding sudo rules. Thanks! Should we drop the IMO broken PAM configs as well? I volunteer to do a PR on GitHub if helpful. (In reply to Michael Weiser from comment #6) > Thanks! Should we drop the IMO broken PAM configs as well? I volunteer to do > a PR on GitHub if helpful. That would be great. I am not really a pam expert so I'd like to have your forthcoming PR reviewed by some other Gentoo devs. BTW: Upstream is aware of us: https://github.com/shadow-maint/shadow/pull/199 and reconsidering the default of --enable-account-tools-setuid. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c7da130a443ab9811b242ae2cbf8259cb85d43b1 commit c7da130a443ab9811b242ae2cbf8259cb85d43b1 Author: Michael Weiser <michael.weiser@gmx.de> AuthorDate: 2019-12-17 19:02:40 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2020-01-19 01:00:17 +0000 sys-apps/shadow: Revbump to fix up PAM configuration shadow includes a number of administrative account management binaries like useradd, chage and chpasswd, traditionally only useable by root. In shadow they can be compiled with PAM support and installed setuid. PAM configuration can then be used to delegate account management to users other than root. The previous config contained the pam_rootok module to provide default behaviour of allowing account management when called as root. But it also contained pam_permit which would allow everyone else to also do account management without any authentication. To close this loophole we remove pam_permit from the config. Also, chpasswd, chgpasswd and newusers are batch-mode mass-change tools meant for scripting. They only contain PAM support if configure flag --enable-account-tools-setuid is in effect and are then installed setuid root. They should use the same restrictive PAM configuration as their siblings. But with setuid user management tools and PAM support within them disabled by commit f569e607 we can stop installing the configuration files as well. chfn and chsh are intended to be called by the user as self-service tools. For this reason they're always installed setuid root and contain PAM support. They should be allowed to work but maybe not without some prior authentication to avoid attacks such as someone finding an unlocked session and using chfn to redirect phone calls intended for the user to himself. The existing passwd config seems perfect for that and is aptly named in that both tools change user information normally stored in /etc/passwd. groupmems is another user self-service tool. It allows the user to add people to their user-private group, allowing them trusted access to normally private files. It is not installed setuid like chfn and chsh but always contains PAM support. Upstream installs a locked down PAM config by default. Since default shell profiles on Gentoo do not change umask to 0002 when a private user group is in use, impact will only be to allow read access to those additional users by default. Since the idea of adding more users to the user *private* group is questionable, go with upstream's default of locking the PAM config down so that an admin not only needs to make the binary suid but also adjust the PAM config, in the process hopefully considering what they're doing. Bug: https://bugs.gentoo.org/702252 Closes: https://github.com/gentoo/gentoo/pull/14032 Reviewed-by: Mikle Kolyada <zlogene@gentoo.org> Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> sys-apps/shadow/files/pam.d-include/shadow-r1 | 7 + sys-apps/shadow/shadow-4.8-r3.ebuild | 233 ++++++++++++++++++++++++++ 2 files changed, 240 insertions(+) Lets get this stable. s390 stable amd64 stable sparc stable arm stable ppc stable x86 stable ia64 stable ppc64 stable arm64 stable hppa stable SuperH port disbanded. m68k dropped stable keywords @maintainer(s), please cleanup The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=56a1b1be9d9b3661cc4f2ab036312d47892c4118 commit 56a1b1be9d9b3661cc4f2ab036312d47892c4118 Author: Lars Wendler <polynomial-c@gentoo.org> AuthorDate: 2020-04-21 08:13:36 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2020-04-21 08:24:39 +0000 sys-apps/shadow: Security cleanup Bug: https://bugs.gentoo.org/702252 Package-Manager: Portage-2.3.99, Repoman-2.3.22 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> sys-apps/shadow/Manifest | 2 - sys-apps/shadow/files/shadow-4.7-optional_su.patch | 130 ------------ sys-apps/shadow/shadow-4.6.ebuild | 214 ------------------- sys-apps/shadow/shadow-4.7-r2.ebuild | 236 --------------------- 4 files changed, 582 deletions(-) Unable to check for sanity:
> no match for package: sys-apps/shadow-4.8-r4
This issue was resolved and addressed in GLSA 202008-09 at https://security.gentoo.org/glsa/202008-09 by GLSA coordinator Sam James (sam_c). We have an embedded ppc, 32 bits with sys-apps/shadow-4.6 USE=nls pam xattr -acl -audit -cracklib -selinux -skey which has ls -l /usr/sbin/{groupadd,groupdel,groupmod,useradd,userdel,usermod} -rwxr-xr-x 1 root root 66396 Mar 28 2019 /usr/sbin/groupadd* -rwxr-xr-x 1 root root 62212 Mar 28 2019 /usr/sbin/groupdel* -rwxr-xr-x 1 root root 66368 Mar 28 2019 /usr/sbin/groupmod* -rwxr-xr-x 1 root root 103748 Mar 28 2019 /usr/sbin/useradd* -rwxr-xr-x 1 root root 70448 Mar 28 2019 /usr/sbin/userdel* -rwxr-xr-x 1 root root 99580 Mar 28 2019 /usr/sbin/usermod* So I suspect this version is not vulnerable ? |