Re: xterm terminal crash due to malicious character sequences in file name

[Vincent Lefevre <vincent () vinc17 net>]

Hi Erik,

On 2025-08-17 16:09:37 +0200, Erik Auerswald wrote:
> On Sun, Aug 17, 2025 at 03:09:58AM +0200, Vincent Lefevre wrote:
> > I see this more than a feature, at least in the case the output
> > is done to a terminal. As a general rule, programs are expected
> > to sanitize output data in such as a case.
>
> I'd expect most programs to not change the filename printed in their
> output.  POSIX does not even expect "ls" to sanitize its output without
> "-q", but it does allow it[0].

Probably because of historical behavior. But nowadays, one should be
stricter concerning security.

> Two more example programs that do not sanitize filenames in their
> output would be "file", at least version "5.41",

file 5.46 sanitizes filenames:

$ file --version
file-5.46
magic file from /etc/magic:/usr/share/misc/magic
$ file file*
file\033[H\033[c\012\010: empty

> and "dash", at least the version[1] included in Ubuntu GNU/Linux
> 22.04.5 LTS.

Ditto for dash 0.5.12-12 (with "chmod 0 file*" then "dash file*").

> I'd expect that you can find many more examples. Getting every
> program changed to follow your expectation seems like a Sisyphean
> task to me.

This is less an issue for dash, because the user will probably not
run a script that he hasn't written or controled in some other way.

> I am quite sure that there are many more such programs.

GNU ed too. It outputs the file name unsanitized in its error message
saying that control characters 1-31 are not allowed in file name!

-- 
Vincent Lefèvre <vincent () vinc17 net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)