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
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:
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.
"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):
- 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
So, we're waiting on stabilization.
Sanity check failed:
> depend amd64 dev profile default/linux/amd64/17.0/no-multilib/prefix/kernel-3.2+ (36 total)
> depend amd64 stable profile default/linux/amd64/17.1 (65 total)
> rdepend amd64 dev profile default/linux/amd64/17.0/no-multilib/prefix/kernel-3.2+ (36 total)
> rdepend amd64 stable profile default/linux/amd64/17.1 (65 total)
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):
Author: Hank Leininger <firstname.lastname@example.org>
AuthorDate: 2019-12-11 22:06:45 +0000
Commit: Lars Wendler <email@example.com>
CommitDate: 2021-01-07 00:48:45 +0000
app-shells/bash: fix CVE-2019-18276 (priv-dropping bug)
Cherry-picked the relevant parts of
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 <firstname.lastname@example.org>
Package-Manager: Portage-2.3.81, Repoman-2.3.18
Signed-off-by: Lars Wendler <email@example.com>
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(+)
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).