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