[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...

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

[corty]

system() invokes a shell

[anthk]

Good to know, now I can patch sacc in order to run lynx under a new shell.