BASH_CMDS is writable in restricted bash shells (fixed upstream, need to backport patch)

[Andrew Zonenberg]

In 14.04 LTS, the BASH_CMDS variable is writable in rbash. This allows a trivial escape from rbash to run arbitrary shell commands.

This issue is fixed upstream: http://git.savannah.gnu.org/cgit/bash.git/tree/CHANGES?h=bash-4.4-testing#n65

[Steve Beattie (sbeattie)]

Hi Andrew, thanks for reporting this. Do you know if a CVE was assigned for this issue?

[Andrew Zonenberg (azonenberg)]

I have not seen a CVE for the original upstream bug but cannot say with certainty none was assigned.

The Ubuntu packaging issue definitely does not have one.

[Seth Arnold (seth-arnold)]

CVE-2019-9924

Thanks

[Riccardo Schirone (rschiron)]

Is this about https://lists.gnu.org/archive/html/bug-bash/2017-03/msg00077.html ? Or about https://lists.gnu.org/archive/html/bug-bash/2017-12/msg00065.html ?

Apparently, both are very old flaws.

[Andrew Zonenberg (azonenberg)]

Yes, that's basically the same issue.

It was patched upstream many years ago (2016 I recall) however as of last fall Ubuntu old-LTS had not backported the fix. I used this bug to escape from rbash during a security audit of a fully patched Ubuntu system in October.

[Seth Arnold (seth-arnold)]

I'm sorry Riccardo, I didn't notice the two separate BASH_CMDS issues when
I filed the request. The only mention in the changelog is:

> This document details the changes between this version, bash-4.4-beta2,
> and the previous version, bash-4.4-rc1.
>$
> [...]
>$
> d. Fixed a bug that allowed assignments to BASH_CMDS when the shell was
> in restricted mode.

http://git.savannah.gnu.org/cgit/bash.git/tree/CHANGES?h=bash-4.4-testing#n65

I did not find a single well-defined patch or commit for this, so
completely overlooked that there are multiple issues.

Thanks

[Riccardo Schirone (rschiron)]

I don't think they are the same issue. Or, at least, the first issue was only partially fixed. I can see both Fedora 29 and Ubuntu 18.10 being still affected by the issue outlined in https://lists.gnu.org/archive/html/bug-bash/2017-12/msg00065.html, though they are not affected by https://lists.gnu.org/archive/html/bug-bash/2017-03/msg00077.html.

[Riccardo Schirone (rschiron)]

After looking a bit more into this, it seems the issue in https://lists.gnu.org/archive/html/bug-bash/2017-12/msg00065.html is maybe not a real security concern, since rbash was wrongly configured. Having . in PATH is not good with rbash and that makes the whole thing flawed. So, we could say CVE-2019-9924 is just for the issue in https://lists.gnu.org/archive/html/bug-bash/2017-03/msg00077.html .

[Andrew Zonenberg (azonenberg)]

@Ricardo: Yes, that was my intent with the original report. I didn't even know about the other issue when I submitted this issue.

[Launchpad Janitor (janitor)]

This bug was fixed in the package bash - 4.3-14ubuntu1.4

---------------
bash (4.3-14ubuntu1.4) xenial-security; urgency=medium

  * SECURITY UPDATE: rbash restriction bypass (LP: #1803441)
    - debian/patches/CVE-2019-9924.patch: if the shell is restricted,
      reject attempts to add pathnames containing slashes to the hash table
      in variables.c.
    - CVE-2019-9924

 -- Marc Deslauriers <email address hidden> Fri, 12 Jul 2019 14:25:28 -0400

[Leonidas S. Barbosa (leosilvab)]

Fixed released https://usn.ubuntu.com/4058-2/