“Should I pipe it?”
So, fellow developers, you know how we’re all told not to pipe installation scripts into our shells and yet we all do it anyway? I just rolled a little something that might help with that…
Here’s an example of the nvm install script, verified by yours truly:
What do you think?
Anyone with a GitHub account can help verify installation scripts (would be good to have two more for nvm).
@brad Hey Bradley, about to hit the sack as it’s past 1AM here but let me know what you had in mind. Do you mean something that returns a very basic version that you can curl/wget? Would like to understand your use case :) (Will check back tomorrow.)
@brad Gotcha, thanks. Will have a think :)
@aral I wish Debian and most popular distro would ship a CLI tool that does that kind of thing (like checking signature or whatever is deemed good enough)
There might be tools that people can install on their machine for this - or this webpage you made is pretty useful, but in the end of the day, people like curl|bash because it's a copypastable CLI one-liner that has basically zero dependencies (well, curl..)
Also to me it's never clear to me why curl|bash is so controversed in the first place ... Like what's the threat model ? Each time I see people arguing about it on the internet, it's always a confused discussion between authenticity, integrity, trust in the authors, trust in the transport protocols, and "what !? you don't read every line of code that runs on your computer !?" ... And ultimately people don't scream that much when it's about "double-clicking on obscure .exe found on google" or "apt install foobar"
I suppose curl|bash for some reason just shows how in everyday life we rely on trust when we run software and it makes us afraid that we can run random code so easily. Ultimately there are very few contexts in which there are clear information about how code is (or not) audited and peer-reviewed before we run it on our machines. Typically it's not clear for me if and how much code is audited in Debian before being available in repos...
(sry I'm thinking out loud at this stage)
Will have a think.
Adding a pipe to the pipe is the only way to really solve that.
But could also mark scripts hosted on well-known sites like GitHub and GitLab more trusted as that wouldn’t be an attack vector (unless they’ve been backdoored by government actors).
@aral it’s reallly cool. I always thought something like a sandbox a script could run in, and report all the changes a script actually does. wouldn’t replace human verifiers, and a report would be just as easy to hide malicious trickery in as a script. something satisfying about the idea of a “dry run” though. maybe a script like nvm mucks up my path in ways i don’t want and i’d like to know about it.
@aral Checked it with PiHole curl, because I've always felt overwhelmed by it.
@mplammers Wow, what are they doing in that script, seriously? Will take a look when I have some time. I thought I was being generous with the 100K limit (it’s there to stop the site getting overwhelmed by maliciously large content.)
@aral It honestly doesn't look like something malicious is going on in that script, and it's very well commented. Don't feel obliged to look into it for me, just wanted to share the result. I think "should-i-pipe-it" is a splendid idea.
@aral This seems fundamentally vulnerable to TOCTOU attacks
@jookia It doesn’t cache the script but there is of course the possibility that the site could serve one thing to Should I pipe it? and something else to everyone else. Will have a think about that.
The only way to fully mitigate any attack would be to have Should I pipe it? included in the pipe itself but I’m hesitant to include a centralised single point of failure into install scripts. It would make that site the focus of attacks. This is meant as guidance / better than nothing / awareness.
@aral Having people just check hashes would be a start.
@aral gives me a HTTPS error on firefox if I type two "https://"
@oreolek It’s odd, I’ve run into it randomly a couple of times. Looks like a bug in Firefox. If you press return a couple of times/refresh it finally works.
@aral I feel like this would be really great as some kind of add-on to your terminal that somehow detects piping to shells and runs the script through a text-based version of this site, displaying the results in the terminal with a prompt to ask the user if they want to continue based on the results.
Then you could promote it as a way to automatically ensure that anything you pipe to shell is safe.
although, it would need to be installable in some way other than piping to shell
One thought on the security: Do you fake a real client?
- Use a curl/wget User-Agent
- Use changing (unpredictable) dial-up IPs and no data center / proxy / tor IPs.
Otherwise I could serve the site a harmless script and send the users an evil script.
An even better option could be to check the script and then offer a button to download the checked script. This would mitigate the problem and even in the case of an attacker who serves different scripts, the user gets the harmless one.
@aral Nice idea! IMHO the best answer is always a strict "no" (especially b/c bash doesn't exhaust input before executing: https://thomask.sdf.org/blog/2019/11/09/take-care-editing-bash-scripts.html) but the pattern is probably here to stay, so it's nice that we now have a tool to verify these scripts.
If it were me I'd make the banner yellow instead of green (which implies complete safety) and add sth to the effect of "Hey, whatever this page says, piping to shell is bad practice, so we suggest you download, read, and run the script manually."
@cadadr Yeah, I hear you on the yellow/green. Actually went back/forth on that and I’m not convinced either. Will consider it.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!