Hacker News Reader

Comment by mrspuratic | Hacker News Reader

"curl ... | bash" makes me run away from a project.

There is the reductive argument that basically everything you download is arbitrary code, but throwing away the code that is run seems uniquely silly.

https://news.ycombinator.com/item?id=21490151

View on HN

Agreed. Perhaps the most prominent example of this shameful behavior is this one:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Source: https://www.rust-lang.org/tools/install

Haha. This is the most secure part. When you start compiling, rust will happily download random "crates" and include them in your program, because "dependencies".

"curl | bash" is the exact same threat vector as "download this compiled installer". I wonder why that doesn't result in the same hyperbolic responses.

The difference is that "curl | bash" doesn't save the output and can be distinguished server-side from commands that do <https://news.ycombinator.com/item?id=34145799>, so it's an especially easy way for a malicious server to undetectably have you run something different from what you've looked over.

So you're saying it's exactly the same as binary installers, which frequently download additional components during installation?

When binary installers download additional components, they usually do so in a way indistinguishable server-side from downloading a file to analyze.

Honest ones, sure. Why would a malicious one leave behind evidence of its malicious behavior? The threat model is identical.

But that behavior would be noticeable in the original download, which would be evidence itself.

Pipe to bash install approaches at least can just be snagged with wget to inspect the script without running it, lots of package managers seem harder than that to inspect/predict? Not that there couldn't be sneaky things you'd miss, but at least obvious ones might be detectable...

alright, do

    curl | tee saved.sh | sh

then

Good idea, unless the attacker serves you just more code that fetches and executes a one-off script from memory (and the download link for that is dynamic and only valid once).

we could go down a rabbit hole of various exploits and defenses, but at end of the day it all comes down to trust. If you don't trust the source of the code, it doesn't matter if it comes in via curl or a .deb signed with GPG, you're still trying to run untrusted code. If your threat model is such that you don't want to do that, don't do that. No one's forcing anybody to run curl | sudo bash at gunpoint.

Reply on news.ycombinator.com