An anonymous security researcher writes about web exploits, CSRF, web shells, and data exfiltration techniques.
Commenters repeatedly cite its post showing a server can detect when curl output is piped to bash, in debates about curl-to-bash installers.
No, I'm sorry, I seriously don't understand how that applies in this case. How is "trusting the content you get from `apt-get`/`dpkg`/`pacman`" safer than curling-to-bash? In both cases, you are downloading and installing content from a trusted source (assuming you are curling via https to avoid MITMs). In the curl-to-bash case, you have the _ability_ to at least inspect the code first before you install it (though, realistically, how many folks would really have the dedication and the ability to do so?), whereas with package managers you're installing "blind". Doesn't that make curling-to-bash the _safer_ option?
I clearly must be missing something, here, because everyone decries "curling-to-bash" as a bad security practice, but I haven't seen an explanation of _why_. I tried doing some research for myself - this page[1] suggests that package managers have built-in checksumming and signature verification, but then goes on to propose an attack vector where the load balancer is compromised, so (presumably?) those same checksums/signatures could also be intercepted and faked. This gist[2] has a lot of people speaking against it, but from following those links, the only downside I could see was here[3], pointing out that the shell will keep executing if a connection closes mid-stream - which, yes, is certainly a bad thing and a good argument to use package managers, but not what I would call a security concern (unless you don't trust the entity on the other end of the stream -…
There definitely is a difference. See [1] (or [2] since the original site has misconfigured TLS). Long story short, using some fairly trivial heuristics, a malicious server could change its response when it detects its output being piped to a shell rather than saved to a file. Thus, a security-minded person downloading the file (who could inspect it) would be given a clean copy, but someone less security-minded piping it straight to bash would be given the malicious copy. The security-minded person wouldn't be able to warn people not to pipe the script to a shell, since it appears safe.
[1] https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/
[2] https://web.archive.org/web/20240228190305/https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/
It's been demonstrated that the server can tell if the client is piping or not
https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/
I'm on mobile and this refuses to load due to SSL/HSTS problems. It's an interesting approach if you can get it to load.
Point being... someone clever could make a bad day for the minority of users who do check first (but don't save/run what they explicitly checked)
Running curl, saying "yup that looks good", then adding a pipe achieves little with actual malice. The payload can be completely hidden until it's too late
The phrasing you use is important for any hope at safety - review/run the same downloaded thing.
If you are slightly more paranoid, keep in mind that the file you downloaded for manual inspection may not be the file you download automatically for bash-piping. This article from 2016 was making the rounds on HN about three years ago: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/
Of course for a properly, professionally paranoid person, you would download every component manually and store the received artifacts locally (for caching, reproducibility, TOFU principle and general BCP needs). Then build from those only. In fact, in high-trust environments it's common for CI systems to not be able to hit internet at all.
binary packages, maybe through github releases. debian packages, potentially upstreamed into the package repos (though that's some effort).
It's quite presumptive to presume to know how a target system is to be configured.
no matter which alternative, curl|bash is security risk enough to never use: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/
gpg can help (below from zerotier):
curl -s 'https://raw.githubusercontent.com/zerotier/ZeroTierOne/master/doc/contact%40zerotier.com.gpg' | gpg --import && \
if z=$(curl -s 'https://install.zerotier.com/' | gpg); then echo "$z" | sudo bash; fi
You didn't even take a look at https://get.docker.io
It's still downloading and executing a script, just two steps instead of piping the output straight into bash.
You can't even inspect the code you run when you do curl|bash and the server is able to detect this distinction and hide code when you do a curl and then run bash.
https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/
Your argument is: "we do it and we use GitHub, you can trust us and can trust GitHub, you don't need to verify the code you run."
And devs learn: "Trust me, you don't need to verify the code you run."