[avaloneon]

I'm surprised that no one has yet mentioned that piping curl to bash can be detected by the server (previous discussion at https://news.ycombinator.com/item?id=17636032). This allows an attacker to send different code if it's being piped to bash instead of saved to disk.

IMHO, "curl to shell" is uniquely dangerous, since all the other installation vectors mentioned don't support the bait-and-switch.

[halter73]

To me, this seems like only a slightly more advanced version of sending malicious payloads only to curl user agents and not something uniquely dangerous.

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.

[avaloneon]

Part of the confusion comes from the fact that there are several different points do be discussed, and they're easy to mix up. For instance: software trust in general, web server security vs repository security, reproducibility, etc.

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)

[valleyer]

You might be interested to read the section titled "User-Agent based attacks" of the linked article.

[tedunangst]

You might be interested to read that the timing attack doesn't rely on user agent. It detects what curl is feeding the output into.

[nimih]

The author's rebuttal to user agent attack doesn't rely on how the server decides what content to serve, and so is naturally generalizable to the timing attack. It's unfortunate how that section is named, because it fools people who didn't read the article into thinking they had a novel counterpoint, when in fact the author already anticipated their exact argument.

[theamk]

Their argument is this:

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

[nimih]

If the folks at rust-lang.org are malicious and willing to put in some extremely customized web-server logic to serve up evil code when they think it won't be noticed, why wouldn't they just sneak it into ./configure or some unnoticed corner of the compiler's source or the standard library or a precompiled binary?

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.

[theamk]

I disagree. I think "webserver got hacked, and no one noticed" is a very realistic threat model. The webpage tells me to get a script from "sh.rustup.rs" -- what is the security behind this server? How can I be sure that it was not hacked? If the server was hacked, how long would it be before the hack it is detected?

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.

[tastroder]

An unmodified curl invocation does not require weird timing based attacks, it sends an appropriate user-agent header the server can use (and which the article already adresses).

[y4mi]

different attack vector.

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.

[zshev]

> It opens you up to a literally undetectable attack.

This is the crux of it for me. This is why it is dangerous. The author appears to have overlooked this attack vector entirely.

[vbezhenar]

Is it undetectable? `curl | tee file | bash` should detect IMO.

[tln]

True, you can detect it without a way to stop the damage! Or easier and more thorough,

    curl | bash -x

[y4mi]

Piping through tee doesn't trigger the sever side detection (it doesn't stop to read every few ms) and using the x flag isn't inherited, so it's gone as soon as subshells are invoked, which is pretty normal for an installation script.

This has all been mentioned in the linked comment thread

[tln]

Actually the server side detection in [0] isn't really affected by putting tee in the middle... and neither does -x, of course.

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

[tulunsutao]

Use disposable virtual machine to isolate the damage, while dumping the script, this way we can detect attack without compromising ourself.