
Back to the Future: Unix Wildcards Gone Wild (2014) - pabs3
https://www.defensecode.com/public/DefenseCode_Unix_WildCards_Gone_Wild.txt
======
account42
This has less to do with wildcards and more with passing arbitrary filenames
to commands without making sure they are not interpreted as options. That
these filenames come from the expansion of * is irrelevant - they could just
as well be read from a file. This "vulnerability" doesn't even need to involve
a shell at all - any exec*() with the same arguments will have the same
result.

Most commands provide a "\--" flag to indicate that all further arguments are
not to be interpreted as anything other than filenames/whatever non-option
arguments the command consumes.

~~~
lexfiend
> This "vulnerability" doesn't even need to involve a shell at all - any
> exec*() with the same arguments will have the same result.

Wildcard expansions are done by shells, so no, exec() wouldn't trigger this
"vulnerability".

Unless you're talking about a specific language's exec() that either does its
own wildcard expansion, or actually runs its arguments in a shell.

~~~
7786655
This is really a vulnerability that applies in any case where you pass user
supplied arguments to a command line program. Suppose you have a bunch of
files on a server and you allow the user to send a list of files that they
want to download as tar. You're careful to avoid directory traversal attacks
so you reject filenames that contain slashes. Then, you do:

    
    
        exec(["tar", "cz", ...user_wanted_files])
    

The user sends you a GET
/api/storage/download_tar?files=--checkpoint%3D1&files=--checkpoint-
action%3Dexec%3Dsh+shell.sh which causes you to execute the contents of
shell.sh. No shell, no glob necessary.

To do it correctly, you would have to do:

    
    
        exec(["tar", "cz", "--", ...user_wanted_files])
    

Or add ./ to the start of each filename.

~~~
7786655
And here Google delivers almost this exact vulerability:

[https://offensi.com/2020/08/18/how-to-contact-google-sre-
dro...](https://offensi.com/2020/08/18/how-to-contact-google-sre-dropping-a-
shell-in-cloud-sql/)

>An attempt to modify the database name in the API call from ‘mysql’ into
‘--help’ results into something that surprised us...

------
lexfiend
The simplest mitigation probably bears mentioning: Prepend all wildcarded
relative paths with `./`, because `rm ./*` does what you'd expect.

~~~
pantalaimon
Or get rid of that pesky user leon

------
ananonymoususer
Many tools allow the use of the "\--" argument to stop argument parsing. It's
a clumsy work-around, but it's better than nothing.

------
andrewla
Windows in this regard does it right. It provides standard calls for expanding
globs, but the glob handling is handled purely in the application logic, not
in the shell itself.

There are some advantages to doing this in the shell, but really they are
dwarfed by the problems that are caused by users not being very careful about
quoting and "\--" arguments.

------
Shared404
Huh. A neat hack, I always knew wildcards were risky, but didn't realize quite
how dangerous they could be.

------
mixmastamyk
Sounds like unix filesystems should not allow files named starting with an
“-“.

~~~
0xdeadb00f
Once I knew the trick of putting ./ before the dash ('./-'), I have never had
a problem with files starting with '-'.

~~~
mixmastamyk
There's no problem for folks who know the "secret." But what is the utility?

None, IMHO. I've never named a file starting with a dash in my career or as a
child, except as an experiment to see if it could be done. Files promptly
deleted afterward.

