Re: Bash not escaping escape sequences in directory names

[Andreas Kusalananda Kähäri]

On Mon, Jan 24, 2022 at 10:41:32AM -0500, Chet Ramey wrote:
> On 1/22/22 3:48 PM, Andreas Kusalananda Kähäri wrote:
> > On Sat, Jan 22, 2022 at 01:28:50PM -0500, Chet Ramey wrote:
> > > On 1/22/22 5:52 AM, Andreas Kusalananda Kähäri wrote:
> > > > On Fri, Jan 21, 2022 at 06:33:02PM -0500, Chet Ramey wrote:
> > > > > On 1/21/22 6:13 PM, Mike Jonkmans wrote:
> > > > > > On Fri, Jan 21, 2022 at 03:29:47PM -0500, Chet Ramey wrote:
> > > > > > > On 1/21/22 1:43 AM, Lawrence Velázquez wrote:
> > > > > > > 
> > > > > > > > Personally, I would be
> > > > > > > > less than pleased if my whole terminal turned red just because I
> > > > > > > > changed into a directory that happened to have a weird name.
> > > > > > > 
> > > > > > > A mild annoyance at best, don't you think?
> > > > > > 
> > > > > > Mostly an annoyance, but it has potential to be a security issue.
> > > > > 
> > > > > Highly unlikely. It would require an implausible scenario.
> > > > 
> > > > Mind if I use that quote? :-)
> > > > 
> > > > Example of interesting values to test in PS1, with discussions:
> > > > 
> > > >         https://security.stackexchange.com/q/56307
> > > 
> > > They're all about security issues in terminal emulators, or cat, not bash.
> > > They don't require bash at all.
> > 
> > I totally agree that this is not a vulnerability in bash (or cat), but
> > bash, as opposed to cat, has no requirement to faithfully pass every
> > conceivable escape sequence on to the terminal from $PS1.
> 
> I'd say there's a user expectation for that. That's why the \[ and \]
> escapes exist.

Fair comment.

> > The shell
> > even keeps the PS1 variable's value from its inherited environment
> > without sanitizing it.
> 
> Why would people want bash to second-guess them like that?

I was honestly a bit surprised to see bash picking up PS1 from the
environment.  Why would people want it to do that (i.e. export PS1)?

> > > I will look at doing something here to improve the situation, but I'll 
> > > push
> > > back on the notion that this is a security issue with bash.
> > 
> > Sure.  Bash is just the vector, a carrier of potentially problematic
> > data.  Data that is part of the prompt.
> > 
> > Displaying the prompt should not be dangerous.
> 
> And by the same token, `pwd' and `cd' should not be dangerous, right? As
> I said in my previous message, there is a legitimate reason to make the
> output of the \w and \W escapes visible: not doing so throws off readline's
> redisplay. But let's not take this into the ridiculous.

The cd and pwd utilities are expected to provide particular output.  A
system administrator often sets the bash shell's prompt, and having
the shell output unwanted escape sequences to the terminal through the
prompt may be somewhat of a surprise to users who do not know or care
about modifying PS1 in their startup scripts.

I would personally be happy if the output of the special built-in
formatting codes you mentioned were modified as you suggested.  To make
the prompt safe would include forcing the user to use a pre-defined set
of allowed escapes (e.g., color, as already provided by shells like yash
and zsh).  I understand if this would be a too big change, as it would
undoubtedly break existing setups.

-- 
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden

.