IMHO, "curl to shell" is uniquely dangerous, since all the other installation vectors mentioned don't support the bait-and-switch.
If I was already using curl to predownload and audit the script, I'd probably just execute the script I already downloaded which would be safe. Most of the people piping to bash directly do no auditing at all because they trust the source. If you're going to put a malicious payload in a script, you don't have to be that tricky about it.
Most people wouldn't know anything was up in any event until someone else discovered the attack and started raising a fuss on social media. I don't think serving the malicious script just to people who pipe it to bash (or really just download it slowly for any reason) would stop everyone from finding out. It would just make the malicious script more notable when found.
In this case, even "curl is dangerous" has at least two variations. The first is not knowing what the server is sending, the second is that the server can change what it is sending. My complaint is with the latter.
For example, a file in a repository somewhere or uploaded to a compromised web server is static. Everyone who downloads the file gets the same thing.
A file served by `curl | bash`, however, isn't. The server could send different files at different times of day, or only send malicious payloads to certain IPs (like known TOR exit nodes), or certain geographic locations, etc. which is something no repository I know of is even capable of.
Archives, packages, and installers downloaded from a server (instead of a repository or FTP server or S3 bucket where the attacker controls the file but not the server) share this weakness, so that alone doesn't make curl uniquely dangerous.
Where `curl | bash` differs from installers, however, is that it's interactive, so the server can alter its behavior on the fly. This is dangerous because, with installers, the attacker must commit to sending either a clean or infected payload before the installer can tell them if it's being run or not. In this way, even archives serve as a kind of a poor zero-knowledge proof of what the software is, since the attacker needs to commit to a version before knowing what the user intends to do. There's normally also a file left on disk as well.
With `curl | bash`, however, the server has the unique opportunity to get a callback from the installer before it has finished sending it, which means the server doesn't have to commit to sending malicious code blindly and hoping it's not being saved by someone who intends to audit it. Also, `curl | bash`, by default, leaves no trace, further frustrating auditing/reverse-engineering attempts. (Adding insult to injury, there's no way to check the malicious payload before running it, since running it is what causes it to appear. Even if run inside a VM, this can also be abused by an attacker to try to cover their tracks in real time)
In this way, `curl | bash` allows for obfuscation/anti-debugging techniques that no other method I know of offers. Hence, my opinion that `curl | bash` is "uniquely" dangerous.
Edit: Thinking about this more, this generalizes to any installer that interacts with the network, since all the attacker needs is a way to detect execution and some way to avoid leaving artifacts. In this way, curl is indeed not quite "uniquely" dangerous, since it's tied with other network-based installers. However, since the other popular installation methods don't have the ability to obfuscate their initial payload like this, I think the point still stands. (Obviously feel free to correct me if I overlooked something)
> you’re already trusting the vendor and site, and you’re already going to run the software that install.sh downloads.
I don't see how this makes sense? People do check what they run, and especially for sudo-calling commands.
To be clear, when I go to rust-lang.org, my goal is to download a large amount of extremely complex code that I never plan to audit myself and run it repeatedly on my computer, plus also trust it to download even more code that for the most part I plan to never read, and finally I'm going to trust it to take code and turn it into binaries which at least some of the time will run as root. In fact, it's very hard for me to imagine a scenario where an attacker is able to implement the timing attack in the grandparent post (which, to be clear, is very cool and clever and interesting), but is unable to pwn my computer in a huge number of ways that are both technically simpler and harder for me to detect.
The OP's point, as I understand it, isn't that it's impossible to pwn people via `curl | sh`, it's that in many cases, such an attack doesn't fit into a reasonable threat model.
I have full trust in Rust team, but even kernel.org was hacked once! And the worst part, experienced users won't likely to notice that installer does something weird -- because it is fully opaque, and because it
An alternative approach is a manual "git clone". This is way more secure, because the same endpoint and protocol is used by both new users and devs doing daily work.
Can someone compromise dev account and backdoor git repo? Sure. How long before this is detected? Not very long at all, I bet there are people who work on Rust and watch every incoming change.
by detecting the usage of `curl | bash` you can serve a different script only when someone does it, so someone doing `curl -O /tmp/some_script.sh` to audit the script wont see the harmful code.
It opens you up to a literally undetectable attack.
nonetheless, the point of the article author does have some truth. there is always a degree of trust involved when you're installing binaries from a third party. by using curl|bash you're just increasing the required trust a bit.
This is the crux of it for me. This is why it is dangerous. The author appears to have overlooked this attack vector entirely.
curl | bash -xThis has all been mentioned in the linked comment thread
Good point about -x being fallible to an adversarial script, even a simple set +x would be enough!
Where's the link where this has been mentioned? I missed it.
0: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...