Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAPmip_yNY76cDYU3v=34vYnR2JxyGmDjpjW5d11tzSqSnXrzcw@mail.gmail.com>
Date: Wed, 28 Jan 2026 07:57:15 -0800
From: cyber security <cs7778503@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Clarification: rbash escape via history built-ins

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@...il.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

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.