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

Bug #1803441 reported by Andrew Zonenberg on 2018-11-14
258
This bug affects 1 person
Affects Status Importance Assigned to Milestone
bash (Ubuntu)
Undecided
Unassigned
Trusty
Undecided
Leonidas S. Barbosa

Bug Description

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

CVE References

information type: Private Security → Public Security
Steve Beattie (sbeattie) wrote :

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

Andrew Zonenberg (azonenberg) wrote :

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) wrote :

CVE-2019-9924

Thanks

Andrew Zonenberg (azonenberg) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

@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) wrote :

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

Changed in bash (Ubuntu):
status: New → Fix Released
Changed in bash (Ubuntu Trusty):
status: New → In Progress
assignee: nobody → Leonidas S. Barbosa (leosilvab)
Changed in bash (Ubuntu Trusty):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers