The underlying root problem here is the same as SQL injection or HTML
cross-site scripting attacks. You have data, and you emit it in a
context that is expecting a language/protocol of some sort, not raw
data. You then need to escape anything in your data that could be
misinterpreted as the protocol. We're really lucky that there isn't any
way to make a TTY execute commands or delete files or grant user
permissions.
The terminal is controlled by control characters. When rendering user
data for display on a terminal, the only control character that should
ever pass-through from un-trusted data is "\n", and maybe "\t". All
others have the potential to break the rendering on the terminal in
undesirable ways. The "right solution" is to check whether output is to
a TTY, and if so, escape all control chars other than ["\n","\t"] in
some readable format. If the output is going to a pipe, then it should
not get escaped and it is the pipe reader's responsibility to escape the
data if *it* is the one emitting to a TTY (or never, if the data never
reaches a TTY).
A busybox-style solution might be to make a generic print function that
triggers a TTY-check and caches that flag in a global variable, and then
escapes all control characters other than "\n" and "\t" if it is a
TTY... and probably a feature flag that makes the new print function an
alias for the normal one if disabled. Then review every single utility
that takes un-trusted data and use this new print function instead of
the normal one. You'll run into ambiguity with things like 'cat', where
people might reasonably take pre-rendered TTY protocol and want it to
pass through unchanged. But with 'tar', it's fairly certain that none
of the file names being read from the archive should ever be treated as
pre-rendered TTY.
-Mike C.
On 7/2/24 11:39 AM, Walter Harms wrote:
Hello,
to get rid of the char set problem, i would go for a switch that forces ASCII
(that is what i mean with strict ASCII-only policy).
Allow only printable and force the rest to something like "\0x01" (or "?" but
this may cause other problems).
It should be doable, do not spend to much time with "properly", (i mean ls has
a compareable feature for hidden characters in file names).
Feel free to send a prototype patch, the people on the list will poke it until
it is ready.
good luck
________________________________________
Von: Ian Norton <ian.nor...@entrust.com>
Gesendet: Donnerstag, 27. Juni 2024 20:31:24
An: Walter Harms; busybox@busybox.net
Betreff: Re: Re busybox tar hidden filename exploit
Looking at header_list() and header_verbose_list(). Fixing it _properly_ would
include some awareness of the current charset and terminal type I think.
At the very least I guess we could transform all the escape chars and feed
chars to a “?” maybe?
From: busybox <busybox-boun...@busybox.net> on behalf of Ian Norton
<ian.nor...@entrust.com>
Date: Tuesday, 25 June 2024 at 08:40
To: Walter Harms <wha...@bfs.de>, busybox@busybox.net <busybox@busybox.net>
Subject: [EXTERNAL] Re: Re busybox tar hidden filename exploit
Hi Walter, I had a brief look at if I could submit a patch, but I’m very very
new to the busybox codebase. It appears that the same functions used to print
the filenames to stdout are also shared by a number of other busybox modules. I
_think_
Hi Walter,
I had a brief look at if I could submit a patch, but I’m very very new to the
busybox codebase. It appears that the same functions used to print the
filenames to stdout are also shared by a number of other busybox modules. I
_think_ that the cpio tool has the same flaw.
Something that would escape any non-ascii would have been my first instinct too
though perhaps that would not work so well on non 8-bit charsets.
Ian
From: Walter Harms <wha...@bfs.de>
Date: Monday, 24 June 2024 at 09:04
To: Ian Norton <ian.nor...@entrust.com>, busybox@busybox.net
<busybox@busybox.net>
Subject: [EXTERNAL] AW: Re busybox tar hidden filename exploit
Hi Ian, thx for the report. yes, i did not notice (and yes i check tars with
-vt before installing). what do you expect now ? Do you have patch ? Do you
want to start a discussion about possible solution ? (I use a strict ASCII-only
policy
Hi Ian,
thx for the report. yes, i did not notice (and yes i check tars with -vt before
installing).
what do you expect now ?
Do you have patch ?
Do you want to start a discussion about possible solution ?
(I use a strict ASCII-only policy in my projects to catch other traps also).
What does gnutar do here ?
CU
________________________________________
Von: busybox <busybox-boun...@busybox.net> im Auftrag von Ian Norton
<ian.nor...@entrust.com>
Gesendet: Donnerstag, 13. Juni 2024 19:35:33
An: busybox@busybox.net
Betreff: Re busybox tar hidden filename exploit
Hello all.
A few weeks back I logged
https://urldefense.com/v3/__https://bugs.busybox.net/show_bug.cgi?id=16018__;!!FJ-Y8qCqXTj2!dJ1sS5tgZwT81bEY9M83tem-KWln2_zEMbQ9EzMKX89APlTx7LPOsxyNcm-tWCe9LfGKR4DgVS06NXE$<https://urldefense.com/v3/__https:/bugs.busybox.net/show_bug.cgi?id=16018__;!!FJ-Y8qCqXTj2!dJ1sS5tgZwT81bEY9M83tem-KWln2_zEMbQ9EzMKX89APlTx7LPOsxyNcm-tWCe9LfGKR4DgVS06NXE$>
but it doesn’t seem to have had any attention so I thought I’d reach out here.
The bug in question shouldn’t be a serious issue for any kind of well written
automated scripting, but anyone using a terminal to view tar content before
unpacking could be impacted, allowing an attacker to hide one or more files
from the “tar -tf ARCHIVE” or “tar -xvf ARCHIVE” output on a console.
You could imagine using this method to hide a “.profile” file in an archive
that someone might unpack in their home folder, or worse.
While this would probably require a degree of social engineering or inattention
to exploit, the same issue has been fixed in GNU tar and other archive tools (I
believe libarchive recently fixed this issue).
Many thanks
Ian
Any email and files/attachments transmitted with it are intended solely for the
use of the individual or entity to whom they are addressed. If this message has
been sent to you in error, you must not copy, distribute or disclose of the
information it contains. Please notify Entrust immediately and delete the
message from your system.
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
