Re: shell wildcard expansion (un)safety

[Eli Schwartz <eschwartz () gentoo org>]

On 11/8/24 5:02 PM, Dominik Czarnota wrote:
> This is known since even earlier by the article/disclosure „unix wildcards
> gone wild”:
> https://seclists.org/fulldisclosure/2014/Jun/136
>
> The original article link seems to not work but it can be seen e.g. here:
> https://github.com/Gandosha/gandosha.github.io/blob/master/DefenseCode_Unix_WildCards_Gone_Wild.txt
>
> It shows that in some cases this can lead to code execution, e.g. with „tar
> *”


The earliest version of the Bash Pitfalls guide that includes a warning
about the topic, per the Wayback Machine:

https://web.archive.org/web/20090426020027/https://mywiki.wooledge.org/BashPitfalls#Filenames_with_leading_dashes


Overall, wildcards are just a classic "here is a programming language
footgun, we cannot fix it because the language is backwards compatible
to the 90s and earlier" which amounts to:

people love bash because it's "simple" and "easy" and "anyone can write
a bash script without knowing what they are doing".

Of course, the problem is that people who don't know what they are doing
can then write software (sometimes running as root, other times simply
as any permission context with access to sensitive info), which is quite
dangerous -- people who don't know what they are doing often write
security vulnerabilities in many languages, but it's particularly easy
to do so in a language that by definition lacks rigorous parsing, makes
it challenging to have error conditions be fatal, and is for the most
part designed to take any erroneous code you throw at it and do its best
to execute as much of that code as it can, even if lots of it doesn't
really parse correctly.

... wait a minute, are we talking about PHP after all?


-- 
Eli Schwartz

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature