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. The shell even keeps the PS1 variable's value from its inherited environment without sanitizing it. > 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. It's another thing entirely to accidentally mistype a globbing pattern with rm, or purposefully write and/or run a destructive bash script, which must be allowed. -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
