4 ms·

> 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

> 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 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 :)

015a 5y ago
'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.
- jamescostian 5y ago
  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

015a 5y ago

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

jamescostian 5y ago
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