Comment by shawn
7 years ago
That's mistaken because:
bash -c "`echo echo hi`"
note that `echo echo hi` is fully read, and then (and only then) passed to bash.
ditto for
echo -c "`curl <your url>`"
The curl command isn't detectable as an evaluation because it's fully spliced into the string, then sent to bash. It's easy to imagine setting up a `curl <url> | sponge | bash` middleman, too.
It is impossible in general to know what the downstream user is going to do with the bytes you send. Even bash happens not to cache its input. But technically it could -- it would be entirely valid for bash to read in a buffered mode which waits for EOF before interpreting.
Which part is mistaken?
You're of course correct that the general problem is unsolvable - but the goal is to opportunistically infect people who directly paste the "curl example.com/setup | bash" that's helpfully provided in your getting started guide, without serving an obviously malicious payload to someone who could be inspecting it.
Sorry, 2AM. You're right of course.
I think the real message is that this is a new class of timing attack, and that it should be treated as such. E.g. curl itself needs to be updated to buffer its own output.
Or perhaps people shouldn't curl | bash? I don't want curl to buffer all output, I use it on devices with little RAM and do stream processing.
I disagree. Maybe a new tool that downloads and then runs a script from the interwebs needs to be written, but curl itself does one job and does it well.
I.e., curl is a *nix tool.
4 replies →