CVE-2019-18276 (https://nvd.nist.gov/vuln/detail/CVE-2019-18276): An issue was discovered in disable_priv_mode in shell.c in GNU Bash through 5.0 patch 11. By default, if Bash is run with its effective UID not equal to its real UID, it will drop privileges by setting its effective UID to its real UID. However, it does so incorrectly. On Linux and other systems that support "saved UID" functionality, the saved UID is not dropped. An attacker with command execution in the shell can use "enable -f" for runtime loading of a new builtin, which can be a shared object that calls setuid() and therefore regains privileges. However, binaries running with an effective UID of 0 are unaffected. Note I think actual exposure to this should be minor, because setuid bash is a bad idea anyway, and the normal way for a privileged process (sshd, /bin/login, etc.) to launch bash as a user is to fork, drop privs, and then exec. If they do so correctly, bash won't have any privs to misuse; if they do not, that is a bug in them. There is a patch sitting in bash's devel branch, mixed in with other changes: https://github.com/bminor/bash/commit/951bdaad7a18cc0dc1036bba86b18b90874d39ff The latest release version, 5.0_p11, does not include the fix (despite p11 being released well after that fix was added to devel). I will submit a PR that includes a trimmed-down version of this patch to include only the relevant fixes.
https://github.com/gentoo/gentoo/pull/13941#issuecomment-564759598 "The vulnerability requires suid what we don't do and therefore is not exploitable on reasonable configurations." @maintainer(s), is this included in bug 719942?
(In reply to Sam James (sec padawan) from comment #1) > @maintainer(s), is this included in bug 719942? I don't believe so.
Appears to have been fixed in the release of Bash 5.1. From changelog (https://git.savannah.gnu.org/cgit/bash.git/commit/?id=8868edaf2250e09c4e9a1c75ffe3274f28f38581): shell.c - disable_priv_mode: if we have setres[ug]id, use them over set[ug]id, which only set the save user-id and group-id if the process is running as root. From Ian Eldred Pudney in https://savannah.gnu.org/patch/?9822 So, we're waiting on stabilization.
Sanity check failed: > app-shells/bash-5.1 > depend amd64 dev profile default/linux/amd64/17.0/no-multilib/prefix/kernel-3.2+ (36 total) > >=sys-libs/readline-8.1:0= > depend amd64 stable profile default/linux/amd64/17.1 (65 total) > >=sys-libs/readline-8.1:0= > rdepend amd64 dev profile default/linux/amd64/17.0/no-multilib/prefix/kernel-3.2+ (36 total) > >=sys-libs/readline-8.1:0= > rdepend amd64 stable profile default/linux/amd64/17.1 (65 total) > >=sys-libs/readline-8.1:0=
app-shells/bash-5.1* is not yet ready for stabilization!
Resetting sanity check; package list is empty or all packages are done.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ba53be405112d10b85e88cc2637156804b88bd91 commit ba53be405112d10b85e88cc2637156804b88bd91 Author: Hank Leininger <hlein@korelogic.com> AuthorDate: 2019-12-11 22:06:45 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2021-01-07 00:48:45 +0000 app-shells/bash: fix CVE-2019-18276 (priv-dropping bug) Cherry-picked the relevant parts of https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=951bdaad7a18cc0dc1036bba86b18b90874d39ff and modified the patches to apply. Note that the existing bash-5.0*patch files are applied with -p0, which is not the norm for eapply, etc. I simply followed what was required to work with the rest of the existing patches. Signed-off-by: Hank Leininger <hlein@korelogic.com> Bug: https://bugs.gentoo.org/702488 Package-Manager: Portage-2.3.81, Repoman-2.3.18 Closes: https://github.com/gentoo/gentoo/pull/13941 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> app-shells/bash/bash-5.0_p11-r1.ebuild | 266 +++++++++++++++++++++ .../files/bash-5.0_p11-disable_priv_mode.patch | 85 +++++++ 2 files changed, 351 insertions(+)
x86 done
ppc done
arm64 done
arm done
amd64 done
ppc64 done
sparc done
hppa stable
s390 done all arches done
New GLSA request filed.
This issue was resolved and addressed in GLSA 202105-34 at https://security.gentoo.org/glsa/202105-34 by GLSA coordinator Thomas Deutschmann (whissi).
