[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <B13F08EE-9A89-4D37-AD66-0772C042781D@dwheeler.com>
Date: Sun, 17 Aug 2025 21:44:29 -0400
From: "David A. Wheeler" <dwheeler@...eeler.com>
To: oss-security@...ts.openwall.com
Cc: Vincent Lefevre <vincent@...c17.net>
Subject: Re: xterm terminal crash due to malicious character
sequences in file name
>>>> On Wed, Aug 13, 2025 at 07:00:58PM +0200, Vincent Lefevre wrote:
>>>>>
>>>>> The following makes the xterm terminal crash
>>>>>
>>>>> touch "$(printf "file\e[H\e[c\n\b")"
>>>>> gunzip file*
>>>>>
>>>>> due to malicious character sequences in the file name and a bug
>>>>> in xterm. Same issue with bunzip2 instead of gunzip.
>>>>
>>>> I do not expect this to only happen with gunzip and bzip2.
>>>> Does this happen with any program that prints the filename without
>>>> any escaping, e.g., "echo file*", and most programs that print
>>>> the provided filename
...
On Aug 17, 2025, at 10:09 AM, Erik Auerswald <auerswal@...x-ag.uni-kl.de> wrote:
> 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]. Two more example programs that do not
> sanitize filenames in their output would be "file", at least version
> "5.41", and "dash", at least the version[1] included in Ubuntu GNU/Linux
> 22.04.5 LTS. 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.
>
> Please note that I am not opposed to adding that feature to every
> existing and future program, it just seems foolish to rely on it, at
> least currently.
I agree. It'd be *much* more secure
if the operating simply prevented the creation of filenames
with certain names, e.g,. containing control characters and leading dashes.
I wrote an essay here specifically about this:
https://dwheeler.com/essays/fixing-unix-linux-filenames.html
See section 1.3, "Oh, and don’t display filenames. Filenames could contain
control characters that control the terminal (and X-windows), causing nasty
side-effects on display. Displaying filenames can even cause a security vulnerability —
and who expects printing a filename to be a vulnerability?!?"
It's not a new problem, I knew about this in the 1980s and I'm sure others did too.
I proposed forbidding such characters to POSIX. They *did* add a few mechanisms to POSIX
to make it somewhat easier to handle filenames with control characters
(e.g., find -print0 and xargs -0). However, although they do not *require*
that operating systems allow these filenames, they are not forbidden either.
I have a draft Linux Security Module (LSM) that lets you determine
what kind of filenames are allowed to be created. By default it would require
non-control-chars, no leading '-', no trailing ' ', and UTF-8 encoding,
but it would let you configure further. I intend to go back to that
to finish it off & propose it. My original proposal merely prevented creation;
it would be possible to hide them entirely, but that comes with its own issues.
--- David A. Wheeler
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.
