oss-sec mailing list archives

Re: Clarification: rbash escape via history built-ins


From: cyber security <cs7778503 () gmail com>
Date: Wed, 28 Jan 2026 07:57:15 -0800

Subject: [oss-security] Follow-up: rbash escape via history built-ins

In my earlier message I described how `history -w` can overwrite startup
files in $HOME, breaking confinement in restricted bash.

To add one clarification: even if administrators place users in an
unwritable subdirectory (e.g., $HOME/restricted), symlinks from that
directory back into writable $HOME files (such as .profile) can re-expose
the same vulnerability. This means that simply making the working
directory unwritable is insufficient if symlinks escape into writable
locations.

Recommendation: Restricted environments should ensure $HOME itself is
unwritable, or that the non-writable directory lacks symlinks into
writable paths. This complements the earlier advice about history-writing
built-ins.

-- RelunSec

On Tue, Jan 27, 2026 at 3:33 PM cyber security <cs7778503 () gmail com> wrote:

Summary:
Restricted Bash (rbash) blocks output redirection to prevent file modification.
However, history-writing built-ins (`history -w`, `history -a`) can overwrite
startup files such as .profile if the restricted user is left in $HOME.
This allows PATH resets and escape from confinement.

Steps to reproduce:
1. Start rbash in $HOME with writable .profile.
2. Run: history -w .profile
3. On next login, .profile is sourced, PATH is reset, confinement is broken.

Discussion:
The Bash manual notes administrators must configure restricted environments
carefully (unwritable $HOME, different working directory, restricted PATH).
However, this particular escape vector is not documented in common guides
(e.g., https://0xffsec.com/handbook/shells/restricted-shells/).

Recommendation:
While consistent with current design, administrators should be aware that
history-writing built-ins can modify files in the current directory.
Restricted environments should ensure $HOME is unwritable or place users
in a safe subdirectory.

References:
GNU Bash manual:
https://www.gnu.org/software/bash/manual/html_node/The-Restricted-Shell.html

-- RelunSec


Current thread: