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
OpenPGP_signature.asc
Description: OpenPGP digital signature
