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 .
