Hacker News new | ask | show | jobs
by jamescostian 1700 days ago
> The only legitimate risk I've heard about 'curl | bash' is that web servers can detect whether the site is being accessed by a browser versus curl, and serve different content

This is the reason why you shouldn't do curl ... | bash, you should do bash -c "$(curl ...)"

The former is truly vulnerable, for the exact reason you mention, while the latter isn't.

> With curl | bash, the URL of the bash script is right there. I can copy it, plug it into my browser, and inspect with ease the shell script that will run

Not exactly, see http://thejh.net/misc/website-terminal-copy-paste

More savvy users might have set their shell up in a way that mitigates this risk, and some users will, as you mentioned, copy and paste URL, but go ahead and try that with the command in the link I provided - note that if you copy just the git URL, it only copies that bit, and then you can paste it into your browser, and not realize that there's a malicious bit before it

Of course, copying and pasting a command involving apt/dnf/etc is also vulnerable to that same attack :)

1 comments

'bash -c $(curl )' doesn't mitigate a website's ability to detect whether you're downloading a file via curl versus accessing it in a browser (e.g. if (headers.USER_AGENT.includes("curl")) {}).

It does mitigate a different issue whereby the website can detect if you're piping the output of 'curl' directly to bash.

The safest option is definitely --> curl to file, audit what you downloaded locally, not in a browser, then bash -c that downloaded file.

But, again, this only really mitigates attacks from sketchy websites. If the website is trustworthy; both the website you're getting the curl | bash download string from, and the website the script is hosted at, such as Github, where 90% of these scripts are hosted; its not really mitigating a legitimate threat.

The copy-paste thing is interesting, but frankly: That's an argument for why the web is insecure, and that insecurity impacts every single method of software distribution which touches it. Copy-pasting a 'sudo apt-get install' line is the same class of risk here as copy-pasting a 'curl | bash' or 'bash -c $(curl)' line; you could swap the script to a new URL, or you could have them install a malicious package from apt, or even just nuke the apt-get install part and just do a curl | bash anyway. Definitely something that's great to know and educate about, but its not the strongest argument against curl | bash.

I agree 100% with that comment :) Including the first part:

> 'bash -c $(curl )' doesn't mitigate a website's ability to detect whether you're downloading a file via curl versus accessing it in a browser

You're totally right, I forgot about this one! It's wild how many tricks there are in the security world