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

Bug #1803441 reported by Andrew Zonenberg on 2018-11-14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
bash (Ubuntu)
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:

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 :



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.

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


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, though they are not affected by

Riccardo Schirone (rschiron) wrote :

After looking a bit more into this, it seems the issue in 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 .

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