Closed cym13 closed 8 years ago
Thank you for the detailed bug report!
58a801ee08984a547b214cc39b262c23c64693e6 single-quotes filenames to avoid the injection on read.
There is more to do in case of badness in the prepipe command itself, and there is more to do for escaping popen for output.
$ mlr --from 'a;uname -a;.csv' --prepipe "echo" cat
sh: a;uname -a;.csv: No such file or directory
This also needs to escape single-quotes in the "filename", if present. This still gets through:
mlr --from "a';uname -a;'.csv" --prepipe "echo" cat
As of b60e0c32be4d974661a049bf4f518160df4412ac that's blocked too:
$ mlr --from 'a;uname -a;.csv' --prepipe "echo" cat
sh: a;uname -a;.csv: No such file or directory
$ mlr --from "a';uname -a;'.csv" --prepipe "echo" cat
sh: a';uname -a;'.csv: No such file or directory
That looks better. Don't torture yourself with “badness in the prepipe command”, as long as the user can control the command you'll never be able to stop him from doing bad things. Preventing bad things is the user's responsability here.
Thanks @cym13!
What
Using --prepipe to specify a preprocessing command is vulnerable to shell injection.
Proof of concept
While it is well understood that prepipe allows the user to run shell commands, the fact that the filename isn't properly quoted is clearly a bug. All popen calls in miller are affected.
Hypothetical exploitation
Miller is a command-line tool which means it is likely to be integrated to scripts to deal with input automatically.
Let's consider the case of a website getting csv formatted input from users that wants them to be able to send a zipped file (think some accounting software linked to a website to analyze its data).
A malicious user could send a zip file with a specially crafted name like "a;python3 -m http.server;b.csv.zip" and send it, effectively executing remotely a python command launching a web server for further exploration.
This is a high-risk vulnerability that should be fixed ASAP.