3 ms·
Let’s say, for example, that I invite a friend over and offer them a glass of water. Would you be similarly upset to find that I don’t recommend that they first
by cstrahan 4y ago
Let’s say, for example, that I invite a friend over and offer them a glass of water. Would you be similarly upset to find that I don’t recommend that they first send a sample of the water to be tested for purity before consuming said glass of water? I mean, don’t get me wrong, I would be fine with my friend being cautious and wanting to get the water tested (though I doubt that would ever happen in practice)… but if he trusts me to give him clean water, I doubt you’d raise any fuss over him just downing a glass.
Why/how is this any different? Anyone that wants to inspect the shell script can amend that line to first save and view the script. Are you thinking it’s never appropriate to trust such a script implicitly? If that’s the case, I’d love to hear about your workflow for checking the packages you install (e.g. debs can run arbitrary post install scripts, and do you know that a malicious actor with signing keys didn’t taint the binaries therein?), how you inspect all JavaScript for sandbox escaping exploits before viewing anything on the web, how you’ve ensured your hardware itself isn’t backdoored, etc.
The complaints of piping directly into shell from an HTTPS server strikes me as nothing more than a “no real technologists does $THING!” sort of elitism, though I’m open to being shown otherwise. A non-answer would be to propose that one first fetch a package signing key and install from your package manager of choice — if the script we’re complaining about can’t be trusted, there’s no reason to trust that the key file is any better with it being hosted in exactly the same way… unless you’re going to propose that you use something along the lines of web-of-trust to inspire further confidence that the signing key is authentic; at that point, though, your problem is with how 99.9% of third-party software packages (with respect to your distro of choice) are distributed - every PPA I’ve ever seen (docker, mongodb, whatever) at best tells you to fetch a key from some HTTPS server, and that’s all. It would then strike me as suspect to single out curl|bash (while additionally implying something about Rust users).
- jjgreen 4y agoAnyone that wants to inspect the shell script can amend that line to first save and view the script. They can, but they may well not get the same output since, as is well-known, curl | sh can be detected on the server.
- yza 4y agoalso it is well-known that scripts you downloaded can be run locally
- davidatbu 4y agoCan't one do `curl $url | sh -c 'cat > /tmp/file'`?
- remram 4y agoNo
- davidatbu 4y agoMind explaining why? I just tried it, and it works fine.
- remram 4y agoWhen we say "|sh can be detected on the server", this is not it. What you wrote is no different from `curl -o /tmp/file`.
- davidatbu 4y agoIn other words, you are saying that an HTTP server can detect distinguish between when the client is doing `curl $url | sh`, and when the client is doing `curl $url | sh -c 'cat > /tmp/file'`. I'd love to hear the mechanism that the server would use to do that, if you have the time!
- remram 4y agoI'm sorry I just saw this, but the idea is that sh will read as it executes so you can detect it passively. If you make it `sleep 1` you can detect on the server side that your call to send() hangs until sh proceeds, for the same duration as the sleep. You need to put enough content to make the TCP buffers fill up, but that can be done with all those function definitions that you tend to see in those scripts anyway. Or the script could also signal through an active mechanism, a different innocuous-looking HTTP request that makes the server switch the content to a malicious payload if it happens at the same time.