“people telling people to execute arbitrary code over the network”
I’ll play devil’s advocate. :) Very nearly everyone executes arbitrary code over the network to some degree.
My knee-jerk reaction for a very long time was to be shocked and appalled by this practice. “What?! I have a carefully curated list stored inside my apt-key!” – really? How’s your chain of trust? How many key-signing parties have you been to lately? Did you chroot that arbitrary code you pulled from github before you ran it?
If the script is wrapped in https and the curl/wget/etc uses certificate trust, I’m not sure why this is bad. For those of us who care, we pull down the script and read it as we know how to, and then execute the script if we want to, understanding the security implications as best we know how (which is as good as anyone can do). For most people, it’s not significantly different than downloading an .exe or an OSX package or an rpm or a deb or whatever other ways people have decided to zip up bits.
Honest question, though - how is curl https://xxx | sh this any worse than apt or yum or homebrew or pip or gem or InstallShield or whatever else? Almost every installation system I’ve ever met allows me to execute arbitrary code. The exceptions virtually always have security holes. What’s really being added by package management (to security) beyond TLS?
edited to add: “I’m not sure why this is bad” should be replaced with “I’m not sure why this is worse than the previous norms”. I think there are tremendous opportunities for improving UX for security, and this is just one small example.
I’ve read about one problem with curl | sh: if curl fails with an error in the middle of a download, the incomplete script is still sent to sh to be executed. So a line “rm -rf /usr/bin/some-app” might be truncated into “rm -rf /”. The solution is to download the file completely first, and then run it with sh.
However, this blog doesn’t look like it thinks failing downloads are the only problem with curl | sh.
You can mitigate this hazard by wrapping the “bulk” of the script in a function which is then executed at the very end of the file. Of course there’s no way of knowing whether an install script does this without inspecting it first anyway.
My knee-jerk reaction for a very long time was to be shocked and appalled by this practice. “What?! I have a carefully curated list stored inside my apt-key!” – really? How’s your chain of trust? How many key-signing parties have you been to lately? Did you chroot that arbitrary code you pulled from github before you ran it?
If you’re using vanilla Debian then one can’t become a packager without having had one’s key signed by a member of the project (which they’re at least supposed to check your identity against a government-issued ID before doing - certainly the two who signed my key did), and those packagers in turn are supposed to read the source/changes before packaging (which happens with a script they write, not something from upstream). No way to guarantee that they are, but that’s what signing off on it’s supposed to mean, and everyone I’ve known has taken their duties seriously.
The people who write code that works with curl | sh surely know about the security risks, and continue to use it - in part because the alternatives are much worse (from a usability perspective).
“(If you’re concerned about curl | sudo sh, please keep reading. Disclaimer below.)”
…
“This brings me to one other point: some people, and somewhat rightfully so, get very upset when we tell you to curl | sudo sh. And they should be! Basically, when you do this, you are trusting that the good people who maintain Rust aren’t going to hack your computer and do bad things. That’s a good instinct! If you’re one of those people, please check out the documentation on building Rust from Source, or the official binary downloads. And we promise that this method will not be the way to install Rust forever: it’s just the easiest way to keep people updated while Rust is in its alpha state.”
I go back and forth on this one. I sometimes get really offended by e.g. the use of sudo, but then eh, the Unix security model is irretrievably broken anyway. Part of my knee-jerk reaction to the curl | sh is just how so very obvious it makes it that we are only nominally in control of the software that executes on our computers.
A little bit off-topic, but I would like to have the possibility to confine all applications, so that I would know if an application accesses to data that is private, accesses to my local network, etc. And if an application does it, that I could granularly give permissions to the programs. I mean I feel more secure with Android Apps on my phone than with Skype on my Linux box. And if I understand it correctly it is possible with SeLinux or AppArmor. So it would be great for major Linux distributions come preconfigured in such a way. Especially that we have now closed source programs like Skype that are basically black boxes. I think there is this need for something like this especially since Snowden.
“people telling people to execute arbitrary code over the network”
I’ll play devil’s advocate. :) Very nearly everyone executes arbitrary code over the network to some degree.
My knee-jerk reaction for a very long time was to be shocked and appalled by this practice. “What?! I have a carefully curated list stored inside my
apt-key!” – really? How’s your chain of trust? How many key-signing parties have you been to lately? Did you chroot that arbitrary code you pulled from github before you ran it?If the script is wrapped in https and the curl/wget/etc uses certificate trust, I’m not sure why this is bad. For those of us who care, we pull down the script and read it as we know how to, and then execute the script if we want to, understanding the security implications as best we know how (which is as good as anyone can do). For most people, it’s not significantly different than downloading an .exe or an OSX package or an rpm or a deb or whatever other ways people have decided to zip up bits.
Honest question, though - how is
curl https://xxx | shthis any worse than apt or yum or homebrew or pip or gem or InstallShield or whatever else? Almost every installation system I’ve ever met allows me to execute arbitrary code. The exceptions virtually always have security holes. What’s really being added by package management (to security) beyond TLS?edited to add: “I’m not sure why this is bad” should be replaced with “I’m not sure why this is worse than the previous norms”. I think there are tremendous opportunities for improving UX for security, and this is just one small example.
I’ve read about one problem with
curl | sh: ifcurlfails with an error in the middle of a download, the incomplete script is still sent toshto be executed. So a line “rm -rf /usr/bin/some-app” might be truncated into “rm -rf /”. The solution is to download the file completely first, and then run it withsh.However, this blog doesn’t look like it thinks failing downloads are the only problem with
curl | sh.You can mitigate this hazard by wrapping the “bulk” of the script in a function which is then executed at the very end of the file. Of course there’s no way of knowing whether an install script does this without inspecting it first anyway.
If you’re using vanilla Debian then one can’t become a packager without having had one’s key signed by a member of the project (which they’re at least supposed to check your identity against a government-issued ID before doing - certainly the two who signed my key did), and those packagers in turn are supposed to read the source/changes before packaging (which happens with a script they write, not something from upstream). No way to guarantee that they are, but that’s what signing off on it’s supposed to mean, and everyone I’ve known has taken their duties seriously.
The people who write code that works with curl | sh surely know about the security risks, and continue to use it - in part because the alternatives are much worse (from a usability perspective).
The next line of the install guide is:
“(If you’re concerned about curl | sudo sh, please keep reading. Disclaimer below.)”
…
“This brings me to one other point: some people, and somewhat rightfully so, get very upset when we tell you to curl | sudo sh. And they should be! Basically, when you do this, you are trusting that the good people who maintain Rust aren’t going to hack your computer and do bad things. That’s a good instinct! If you’re one of those people, please check out the documentation on building Rust from Source, or the official binary downloads. And we promise that this method will not be the way to install Rust forever: it’s just the easiest way to keep people updated while Rust is in its alpha state.”
bonus points for not even using SSL/TLS:
http://curlpipesh.tumblr.com/post/89999467316/better-be-safe-than-sorry-in-case-it-checks-the
I go back and forth on this one. I sometimes get really offended by e.g. the use of sudo, but then eh, the Unix security model is irretrievably broken anyway. Part of my knee-jerk reaction to the curl | sh is just how so very obvious it makes it that we are only nominally in control of the software that executes on our computers.
A little bit off-topic, but I would like to have the possibility to confine all applications, so that I would know if an application accesses to data that is private, accesses to my local network, etc. And if an application does it, that I could granularly give permissions to the programs. I mean I feel more secure with Android Apps on my phone than with Skype on my Linux box. And if I understand it correctly it is possible with SeLinux or AppArmor. So it would be great for major Linux distributions come preconfigured in such a way. Especially that we have now closed source programs like Skype that are basically black boxes. I think there is this need for something like this especially since Snowden.
While we are at the topic, be sure to review commands from websites and not use copy-paste. There’s a nice CSS trick which will bite you otherwise.