Re busybox tar hidden filename exploit

[Ian Norton]

Hello all.

A few weeks back I logged https://bugs.busybox.net/show_bug.cgi?id=16018 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

AW: Re busybox tar hidden filename exploit

[Walter Harms]

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  im Auftrag von Ian Norton 

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://bugs.busybox.net/show_bug.cgi?id=16018 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

Re: Re busybox tar hidden filename exploit

[Ian Norton]

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 
Date: Monday, 24 June 2024 at 09:04
To: Ian Norton , 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  im Auftrag von Ian Norton 


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

Re: Re busybox tar hidden filename exploit

[Ian Norton]

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  on behalf of Ian Norton 

Date: Tuesday, 25 June 2024 at 08:40
To: Walter Harms , 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 
Date: Monday, 24 June 2024 at 09:04
To: Ian Norton , 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  im Auftrag von Ian Norton 


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

AW: Re busybox tar hidden filename exploit

[Walter Harms]

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 
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  on behalf of Ian Norton 

Date: Tuesday, 25 June 2024 at 08:40
To: Walter Harms , 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 
Date: Monday, 24 June 2024 at 09:04
To: Ian Norton , 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  im Auftrag von Ian Norton 


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

Re: Re busybox tar hidden filename exploit

[Kang-Che Sung]

From: Ian Norton
>
> 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.

From: Walter Harms
>
> What does gnutar do here  ?
>

Hey. Did you guys read this section in GNN find manual?

"Safe File Name Handling"
https://www.gnu.org/software/findutils/manual/html_node/find_html/Safe-File-Name-Handling.html

When it comes to unusual filenames, the GNU way of doing it is implementing
a `--null` option that accepts the list of filenames separated by ASCII NUL
characters.

Various other utilities can print the filename list with NUL as the
separator. For example `-print0` command in `find(1)`.

These are how GNU utilities handle unusual filenames.

It might not sound like a good idea to implement something that escape
filenames during output (such as GNU ls(1) `--quoting-style` option),
because a lot of utilities would need it, and I believe it's not the Unix
way of doing things. Filename quoting and escaping should ideally be it's
own utility (the closest I could find is `od -c`, although it's not in the
quoting style people are familiar with).
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Re busybox tar hidden filename exploit

[Steffen Nurpmeso]

Kang-Che Sung wrote in
 :
 ...
 |When it comes to unusual filenames, the GNU way of doing it is implementing
 |a `--null` option that accepts the list of filenames separated by ASCII NUL
 |characters.
 |
 |Various other utilities can print the filename list with NUL as the
 |separator. For example `-print0` command in `find(1)`.

This (at least, too lazy to look) is also part of the new POSIX
standard released in June.  Ie, going that NUL thing seems "to
come", it *could* be that there are other issues lying around for
the next standard.

  ...

(Nonetheless quoting in the shell language is a must

  80092  The application shall quote the following characters if they 
are to represent themselves:
  80093  |& ;<>   ()$`\ "'
   

and POSIX 2024 adds the $'' dollar single quote mechanism (dash is
about to implement it / has just recently done so), and for tools
producing output for the (interaction with the) shell that thus
seems useful to have; i do not know how portable "IFS= xy" is..)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Re busybox tar hidden filename exploit

[Kang-Che Sung]

Steffen Nurpmeso  於 2024年7月3日 星期三寫道：
> Kang-Che Sung wrote in

>  |When it comes to unusual filenames, the GNU way of doing it is
implementing
>  |a `--null` option that accepts the list of filenames separated by ASCII
NUL
>  |characters.
>  |
>  |Various other utilities can print the filename list with NUL as the
>  |separator. For example `-print0` command in `find(1)`.
>
> This (at least, too lazy to look) is also part of the new POSIX
> standard released in June.  Ie, going that NUL thing seems "to
> come", it *could* be that there are other issues lying around for
> the next standard.
>
>   ...
>
> (Nonetheless quoting in the shell language is a must
>
>   80092  The application shall quote the following characters if
they are to represent themselves:
>   80093  |& ;<>   ()$`\ "
'   
>
> and POSIX 2024 adds the $'' dollar single quote mechanism (dash is
> about to implement it / has just recently done so), and for tools
> producing output for the (interaction with the) shell that thus
> seems useful to have; i do not know how portable "IFS= xy" is..)
>

Just FYI, there is a portable alternative to the $'' (dollar-single-quote)
of passing special characters in the shell. It's $(printf '...') with
command substitution.

It is useful if the special characters are known ahead of time, and it's
not a complete substitute of `ls --quoting-style=shell` nor `ls --zero`.

I'm not sure what the use case of the original reporter (Ian Norton) is,
but it's simply not part of the goal for `tar -tf foo.tar` to output or
escape special characters in filenames.

In other words, there's no bug here, just a UX inconvenience that special
characters are not displayed properly.

* If you want a secure protocol for outputting filenames or accepting
filenames in tar(1) and other utilities, then the `--null` option is the
way to go. Human readability of the filenames is second for this use case.
* If you want outputting filenames with human readability and all special
characters escaped, then GNU tar has the `--quoting-style` option that
busybox can consider implementing too, but keep in mind that this is meant
for _output_ only, not for secure _input_ of filenames. (Besides, I don't
know if it would escape problematic Unicode control characters. There was a
Unicode Bidi vulnerability nicknamed "Trojan Source" that you might be
interested in knowing.)
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Re busybox tar hidden filename exploit

[Steffen Nurpmeso]

Kang-Che Sung wrote in
 :
 |Steffen Nurpmeso  於 2024年7月3日 星期三寫道：
 |> Kang-Che Sung wrote in
 |>|When it comes to unusual filenames, the GNU way of doing it is
 |implementing
 |>|a `--null` option that accepts the list of filenames separated by ASCII
 |NUL
 |>|characters.
 |>|
 |>|Various other utilities can print the filename list with NUL as the
 |>|separator. For example `-print0` command in `find(1)`.
 |>
 |> This (at least, too lazy to look) is also part of the new POSIX
 |> standard released in June.  Ie, going that NUL thing seems "to
 |> come", it *could* be that there are other issues lying around for
 |> the next standard.
 |>
 |>   ...
 |>
 |> (Nonetheless quoting in the shell language is a must
 |>
 |>   80092  The application shall quote the following characters if
 |they are to represent themselves:
 |>   80093  |& ;<>   ()$`\ "
 |'   
 |>
 |> and POSIX 2024 adds the $'' dollar single quote mechanism (dash is
 |> about to implement it / has just recently done so), and for tools
 |> producing output for the (interaction with the) shell that thus
 |> seems useful to have; i do not know how portable "IFS= xy" is..)
 |>
 |
 |Just FYI, there is a portable alternative to the $'' (dollar-single-quote)
 |of passing special characters in the shell. It's $(printf '...') with
 |command substitution.

You mean the %q format?  That is not standardized.

   %q ARGUMENT is printed in a format that can be reused as  shell  in-
  put,  escaping  non-printable  characters with the proposed POSIX
  $'' syntax.

Just like bash(1)s ${parameter@operator}:

Q  The expansion is a string that is the value  of  parameter
   quoted in a format that can be reused as input.

 |It is useful if the special characters are known ahead of time, and it's
 |not a complete substitute of `ls --quoting-style=shell` nor `ls --zero`.

Hm.

 |I'm not sure what the use case of the original reporter (Ian Norton) is,
 |but it's simply not part of the goal for `tar -tf foo.tar` to output or
 |escape special characters in filenames.
 |
 |In other words, there's no bug here, just a UX inconvenience that special
 |characters are not displayed properly.
 |
 |* If you want a secure protocol for outputting filenames or accepting
 |filenames in tar(1) and other utilities, then the `--null` option is the
 |way to go. Human readability of the filenames is second for this use case.

Well one could look for isatty(3) for example.
Things are easier if you also know you are in a Unicode-aware
environment, then you can simply add U+2400 aka do

 if(!iswprint(wc) && wc != '\n' /*&& wc != '\r' && wc != '\b'*/ &&
   wc != '\t'){
if ((wc & ~S(wchar_t,037)) == 0)
   wc = isuni ? 0x2400 | wc : '?';
else if(wc == 0177)
   wc = isuni ? 0x2421 : '?';
else
   wc = isuni ? 0x2426 : '?';

but in other cases have to be aware of L-TO-R and R-TO-R marks,
zero width and non-characters, ie most brutal (where isuni tells
us that the character set aka wchar_t is real Unicode).

   }else if(isuni){ /* TODO ctext */
  /* Need to filter out L-TO-R and R-TO-R marks TODO ctext */
  if(wc == 0x200E || wc == 0x200F || (wc >= 0x202A && wc <= 0x202E))
 continue;
  /* And some zero-width messes */
  if(wc == 0x00AD || (wc >= 0x200B && wc <= 0x200D))
 continue;
  /* Oh about the ISO C wide character interfaces, baby! */
  if(wc == 0xFEFF)
 continue;
   }

 |* If you want outputting filenames with human readability and all special
 |characters escaped, then GNU tar has the `--quoting-style` option that
 |busybox can consider implementing too, but keep in mind that this is meant
 |for _output_ only, not for secure _input_ of filenames. (Besides, I don't
 |know if it would escape problematic Unicode control characters. There was a
 |Unicode Bidi vulnerability nicknamed "Trojan Source" that you might be
 |interested in knowing.)

Yes.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Re busybox tar hidden filename exploit

[Kang-Che Sung]

(Sorry if my mail client messes up with the quoting. I use the mobile web
version of Gmail.)

Steffen Nurpmeso  於 2024年7月4日 星期四寫道：
>  |Kang-Che Sung wrote in
>  |
>  |Just FYI, there is a portable alternative to the $''
(dollar-single-quote)
>  |of passing special characters in the shell. It's $(printf '...') with
>  |command substitution.
>
> You mean the %q format?  That is not standardized.
>
>%q ARGUMENT is printed in a format that can be reused as  shell
in-
>   put,  escaping  non-printable  characters with the proposed
POSIX
>   $'' syntax.
>
> Just like bash(1)s ${parameter@operator}:
>
> Q  The expansion is a string that is the value  of  parameter
>quoted in a format that can be reused as input.

I am not expecting any quoted and shell-escaped filename output may be
reused as input. Such quoting and escaping may be useful in filtering
well-known problematic characters (shell meta-characters, quotation marks,
etc.), but would never be complete in mitigating all possible attacks with
the Unicode characters.

That's why I mentioned two use cases, and made them distinct. You can't win
both.

> Well one could look for isatty(3) for example.
> Things are easier if you also know you are in a Unicode-aware
> environment, then you can simply add U+2400 aka do
>
>  if(!iswprint(wc) && wc != '\n' /*&& wc != '\r' && wc != '\b'*/ &&
>wc != '\t'){
> if ((wc & ~S(wchar_t,037)) == 0)
>wc = isuni ? 0x2400 | wc : '?';
> else if(wc == 0177)
>wc = isuni ? 0x2421 : '?';
> else
>wc = isuni ? 0x2426 : '?';
>
> but in other cases have to be aware of L-TO-R and R-TO-R marks,
> zero width and non-characters, ie most brutal (where isuni tells
> us that the character set aka wchar_t is real Unicode).
>
>}else if(isuni){ /* TODO ctext */
>   /* Need to filter out L-TO-R and R-TO-R marks TODO ctext */
>   if(wc == 0x200E || wc == 0x200F || (wc >= 0x202A && wc <=
0x202E))
>  continue;
>   /* And some zero-width messes */
>   if(wc == 0x00AD || (wc >= 0x200B && wc <= 0x200D))
>  continue;
>   /* Oh about the ISO C wide character interfaces, baby! */
>   if(wc == 0xFEFF)
>  continue;
>}

This was the second use case I mentioned. That is,
`--quoting-style=whatever`. We can make this the default when `stdout` is a
terminal, and I believe GNU utilities already did this.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: AW: Re busybox tar hidden filename exploit

[Bernd Petrovitsch]

Hi all!

On 24/06/2024 10:03, Walter Harms wrote:
[...]

what do you expect now ?
Do you have patch ?
Do you want to start a discussion about possible solution ?


Actually such filenames may exist in the filesystem so this point applies
to `ls`, `find`, any other program listing files or handling container too.
So these filenames can actually be no exploit attempt.

Is there an accepted way of quoting filenames (like e.g. in certain situation
does)?


(I use a strict ASCII-only policy in my projects to catch other traps also).
What does gnutar do here  ?


... and/or other tar's (Net/Free/OpenBSD, ...)?)

King regards,
Bernd
--
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 There is NO CLOUD, just other people's computers. - FSFE
 LUGA : http://www.luga.at
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: AW: Re busybox tar hidden filename exploit

[Michael Conrad]

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 
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  on behalf of Ian Norton 

Date: Tuesday, 25 June 2024 at 08:40
To: Walter Harms , 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 
Date: Monday, 24 June 2024 at 09:04
To: Ian Norton , 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  im Auftrag von Ian Norton 


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_zEMbQ9EzMKX89APlTx7L

RE: AW: Re busybox tar hidden filename exploit

[David Laight]

From: Michael Conrad
> Sent: 03 July 2024 01:29
> 
> 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.

I'm sure some terminals supported an escape sequences to write the
terminal 'answerback' message.
(You might need to back to 1980's async terminals.)

Having 'ls' generate the answerback message (unlikely on anything recent)
is mighty confusing - even when not malicious.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [EXTERNAL] Re: Re busybox tar hidden filename exploit

[Ian Norton]

I will try to produce a small patch to solve the main issue (masking filenames 
when listing archive content) my back-of-the napkin idea is to simply replace 
the following bytes with “?” when printing them via the header list function:

0x08 (backspace)
0x09 (htab)
0x0a (line feed)
0x0b (vtab)
0x0c (form feed)
0x0d (carriage return)
0x1b (escape)
0x7f (del)

That should solve the problem while not breaking multi-byte charsets that I can 
tell

PS apologies for the top-posting, I hate outlook!.

From: busybox  on behalf of Kang-Che Sung 

Date: Thursday, 4 July 2024 at 02:20
To: Kang-Che Sung , busybox@busybox.net 

Subject: [EXTERNAL] Re: Re busybox tar hidden filename exploit
(Sorry if my mail client messes up with the quoting. I use the mobile web 
version of Gmail. ) Steffen Nurpmeso  於 2024年7月4日 星期四寫道： 
> |Kang-Che Sung wrote in > | > |Just FYI, there is a portable alternative to

(Sorry if my mail client messes up with the quoting. I use the mobile web 
version of Gmail.)

Steffen Nurpmeso mailto:stef...@sdaoden.eu>> 於 2024年7月4日 
星期四寫道：
>  |Kang-Che Sung wrote in
>  |
>  |Just FYI, there is a portable alternative to the $'' (dollar-single-quote)
>  |of passing special characters in the shell. It's $(printf '...') with
>  |command substitution.
>
> You mean the %q format?  That is not standardized.
>
>%q ARGUMENT is printed in a format that can be reused as  shell  in-
>   put,  escaping  non-printable  characters with the proposed POSIX
>   $'' syntax.
>
> Just like bash(1)s ${parameter@operator}:
>
> Q  The expansion is a string that is the value  of  parameter
>quoted in a format that can be reused as input.

I am not expecting any quoted and shell-escaped filename output may be reused 
as input. Such quoting and escaping may be useful in filtering well-known 
problematic characters (shell meta-characters, quotation marks, etc.), but 
would never be complete in mitigating all possible attacks with the Unicode 
characters.

That's why I mentioned two use cases, and made them distinct. You can't win 
both.

> Well one could look for isatty(3) for example.
> Things are easier if you also know you are in a Unicode-aware
> environment, then you can simply add U+2400 aka do
>
>  if(!iswprint(wc) && wc != '\n' /*&& wc != '\r' && wc != '\b'*/ &&
>wc != '\t'){
> if ((wc & ~S(wchar_t,037)) == 0)
>wc = isuni ? 0x2400 | wc : '?';
> else if(wc == 0177)
>wc = isuni ? 0x2421 : '?';
> else
>wc = isuni ? 0x2426 : '?';
>
> but in other cases have to be aware of L-TO-R and R-TO-R marks,
> zero width and non-characters, ie most brutal (where isuni tells
> us that the character set aka wchar_t is real Unicode).
>
>}else if(isuni){ /* TODO ctext */
>   /* Need to filter out L-TO-R and R-TO-R marks TODO ctext */
>   if(wc == 0x200E || wc == 0x200F || (wc >= 0x202A && wc <= 0x202E))
>  continue;
>   /* And some zero-width messes */
>   if(wc == 0x00AD || (wc >= 0x200B && wc <= 0x200D))
>  continue;
>   /* Oh about the ISO C wide character interfaces, baby! */
>   if(wc == 0xFEFF)
>  continue;
>}

This was the second use case I mentioned. That is, `--quoting-style=whatever`. 
We can make this the default when `stdout` is a terminal, and I believe GNU 
utilities already did this.
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

Re: [EXTERNAL] Re: AW: Re busybox tar hidden filename exploit

[Ian Norton]

From: busybox  on behalf of Michael Conrad 
mcon...@intellitree.com
> 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.

Sadly,  there are some terminals that give more control than they should
https://dgl.cx/2023/09/ansi-terminal-security

The easier and simpler attack here though is masking the content of an archive



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

Re: [EXTERNAL] RE: AW: Re busybox tar hidden filename exploit

[Ian Norton]

On 15 July 2024 16:39 David Laight  wrote:
> On 03 July 2024 01:29 'Michael Conrad'  wrote:
> > 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

> I'm sure some terminals supported an escape sequences to write the
> terminal 'answerback' message.
> (You might need to back to 1980's async terminals.)

> Having 'ls' generate the answerback message (unlikely on anything recent)
> is mighty confusing - even when not malicious.

Take a look at https://dgl.cx/2023/09/ansi-terminal-security. Many of these
Are less than a year ago, popular apps like minty (the Cygwin and git-bash
Terminal and also the basis for Putty) Had an RCE that could be triggered by
ANSI escape codes.

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