curl https://some-url/ | sh
I see this all over the place nowadays, even in communities that, I would think, should be security conscious. How is that safe? What’s stopping the downloaded script from wiping my home directory? If you use this, how can you feel comfortable?
I understand that we have the same problems with the installed application, even if it was downloaded and installed manually. But I feel the bar for making a mistake in a shell script is much lower than in whatever language the main application is written. Don’t we have something better than “sh” for this? Something with less power to do harm?
I usually read it first.
Just use a VM or container for installing software. It can go horribly wrong in a isolated place.
I think safer approach is to:
- Download the script first, review its contents, and then execute.
- Ensure the URL uses HTTPS to reduce the risk of man-in-the-middle attacks
If you’ve downloaded and audited the script, there’s no reason to pipe it from curl to sh, just run it. No https necessary.
Unpopular opinion, these are handy for quickly installing in a new vm or container (usually throwaway) where one don’t have to think much unless the script breaks. People don’t install thing on host or production multiple times, so anything installed there is usually vetted and most of the times from trusted sources like distro repos.
For normal threat model, it is not much different from downloading compiled binary from somewhere other than well trusted repos. Windows software ecosystem is famously infamous for exactly the same but it sticks around still.
I also feel incredibly uncomfortable with this. Ultimately it comes down to if you trust the application or not. If you do then this isn’t really a problem as regardless they’re getting code execution on your machine. If you don’t, well then don’t install the application. In general I don’t like installing applications that aren’t from my distro’s official repositories but mostly because I like knowing at least they trust it and think it’s safe, as opposed to any software that isn’t which is more of an unknown.
Also it’s unlikely for the script to be malicious if the application is not. Further, I’m not sure a manual install really protects anyone from anything. Inexperienced users will go through great lengths and jump through some impressive hoops to try and make something work, to their own detriment sometimes. My favorite example of this is the LTT Linux challenge. apt did EVERYTHING it could think to do to alert that the steam package was broken and he probably didn’t want to install it, and instead of reading the error he just blindly typed out the confirmation statement. Nothing will save a user from ruining their system if they’re bound and determined to do something.
In this case apt should have failed gracefully. There is no reason for it to continue if a package is broken. If you want to force a broken package, that can be it’s own argument.
I’m not sure that would’ve made a difference. It already makes you go out of your way to force a broken package. This has been discussed in places before but the simple fact of the matter is a user that doesn’t understand what they’re doing will perservere. Putting up barriers is a good thing to do to protect users, spending all your time and effort to cover every edge case is a waste of time because users will find ways to shoot themselves in the foot.
You shouldn’t install software from someone you don’t trust anyway because even if the installation process is save, the software itself can do whatever it has permission to.
“So if you trust their software, why not their install script?” you might ask. Well, it is detectable on server side, if you download the script or pipe it into a shell. So even if the vendor it trustworthy, there could be a malicious middle man, that gives you the original and harmless script, when you download it, and serves you a malicious one when you pipe it into your shell.
And I think this is not obvious and very scary.
it is detectable […] server side, if you download the script [vs] pipe it into a shell
I presume you mean if you download the script in a browser, vs using curl to retrieve it, where presumably you are piping it to a shell. Because yeah, the user agent is going to reveal which tool downloaded it, of course. You can use curl to simply retrieve the file without executing it though.
Or are you suggesting that curl makes something different in its request to the server for the file, depending on whether it is saving the file to disk vs streaming it to a pipe?
It is actually a passive detection based of the timing of the chunk requests. Because curl by default will only request new chunks when the buffer is freed by the shell executing the given commands. This then can be used to detect that someone is not merely downloading but simultaneously executing it. Here’s a writeup about it:
You can also find some proof-of-concept implementations online to try it out yourself.
Wow, thanks for this. That is very helpful context. And thanks for your original post too, or I’d never have asked.
It’s not much different from downloading and compiling source code, in terms of risk. A typo in the code could easily wipe home or something like that.
Obviously the package manager repo for your distro is the best option because there’s another layer of checking (in theory), but very often things aren’t in the repos.
The solution really is just backups and snapshots, there are a million ways to lose files or corrupt them.
curl | sudo bash Gang
You have the option of piping it into a file instead, inspecting that file for yourself and then running it, or running it in some sandboxed environment. Ultimately though, if you are downloading software over the internet you have to place a certain amount of trust in the person your downloading the software from. Even if you’re absolutely sure that the download script doesn’t wipe your home directory, you’re going to have to run the program at some point and it could just as easily wipe your home directory at that point instead.
Indeed, looking at the content of the script before running it is what I do if there is no alternative. But some of these scripts are awfully complex, and manually parsing the odd bash stuff is a pain, when all I want to know is : 1) what URL are you downloading stuff from? 2) where are you going to install the stuff?
As for running the program, I would trust it more than a random deployment script. People usually place more emphasis on testing the former, not so much the latter.
All the software I have is downloaded from the internet…
It is kind of cool, when you’ve actually written your own software and use that. But realistically, I’m still getting the compiler from the internet…
You should try downloading the software from your mind brain, like us elite hackers do it. Just dump the binary from memory into a txt file and exe that shit, playa!
You should start getting it from CD-roms, that shit you can trust
I got my software from these free USB sticks I found in the parking lot.
Ah, you’re one of my users
You have the option of piping it into a file instead, inspecting that file for yourself and then running it, or running it in some sandboxed environment.
That’s not what projects recommend though. Many recommend piping the output of an HTTP transfer over the public Internet directly into a shell interpreter. Even just
curl https://... > install.sh; sh install.shwould be one step up. The absolute minimum recommendation IMHO should be
curl https://... > install.sh; less install.sh; sh install.shbut this is still problematic.
Ultimately, installing software is a labourious process which requires care, attention and the informed use of GPG. It shouldn’t be simplified for convenience.
Also, FYI, the word “option” implies that I’m somehow restricted to a limited set of options in how I can use my GNU/Linux computer which is not the case.
I mean if you think that it’s bad for linux culture because you’re teaching newbies the wrong lessons, fair enough.
My point is that most people can parse that they’re essentially asking you to run some commands at a url, and if you have even a fairly basic grasp of linux it’s easy to do that in whatever way you want. I don’t know if I personally would be any happier if people took the time to lecture me on safety habits, because I can interpret the command for myself.
curl https://some-url/ | shis terse and to the point, and I know not to take it completely literally.linux culture
snigger
you’re teaching newbies the wrong lessons
The problem is not that it’s teaching bad lessons, it’s that it’s actually doing bad things.
most people can parse that they’re essentially asking you to run some commands at a url
I know not to take it completely literally
Then it needn’t be written literally.
I think you’re giving the authors of such installation instructions too much credit. I think they intend people to take it literally. I think this because I’ve argued with many of them.
Who the fuck types out “snigger” haha
Teleports behind you
deleted by creator
I usually just take a look at the code with a get request. Then if it looks good, then run manually. Most of the time, it’s fine. Sometimes there’s something that would break something on the system.
I haven’t seen anything explicitly nefarious, but it’s better to be safe than sorry.
Those just don’t get installed. I refuse to install stuff that way. It’s to reminiscent of installing stuff on windows. “Pssst, hey bud, want to run this totally safe executable on your PC? It won’t do anything bad. Pinky promise”. Ain’t happening.
The only exception I make is for nix on non-nixos machines because thwt bootstraps everything and I’ve read that script a few times.
Just direct it into a file, read the script, and run it if you’re happy. It’s just a shorthand that doesn’t require saving the script that will only be used once.
I understand that we have the same problems with the installed application, even if it was downloaded and installed manually. But I feel the bar for making a mistake in a shell script is much lower than in whatever language the main application is written.
So you are concerned with security, but you understand that there aren’t actually any security concerns… and actually you’re worried about coding mistakes in shitty Bash?
This is simpler than the download, ./configure, make, make install steps we had some decades ago, but not all that different in that you wind up with arbitrary, unmanaged stuff.
Preferably use the distro native packages, or else their build system if it’s easily available (e.g. AUR in Arch)
Saved that, thank you.
