12 ms·
curl | sh
- sveredov 12y agoHere is another curlpipesh: https://fixubuntu.com/ https://fixubuntu.com/
- sarciszewski 12y agoExcept, that one shows the full source so you can copy, paste, review, and save it instead.
- ToastyMallows 12y agoYou can do that for all of these, just request the file directly and copy it out of the browser.
- dozzie 12y agoYeah. Of course nobody bothers with providing an installation guide that could be used to build RPM/DEB packages. Because everybody runs `curl | sh` on production machines to install random software.
- TimWolla 12y agoAt least most of the examples are using https.
- sarciszewski 12y agoMojolicio.us is a good counter-example. Unfortunately, they're not on the Tumblr yet.
- marcusramberg 12y agoUnfortunately the default way of installing Perl modules (cpan command line tool). is just as insecure as curl | sh - Note that we have added an example of securely installing Mojo on the homepage as well, if you have configured Perl for signature verification - http://mojolicio.us/ http://mojolicio.us/
- TeeWEE 12y agoNote that dowloading an app (.exe for windows, or an apple app) and running it, is just as bad. Downloading an installer, and running it, is also insecure. So the question is... What is the proper alternative? I think the best alternatives are appstores such as found on ios and android, right? However that doesnt really fit for open source. Is the way to install open source software, to download the source and compile it from scratch? Well, thats also risky, you should check the source code first...? But thats undoable. All in all, it comes down to "trust". Do you trust the website? You dont care about security too much, well, imho then it makes sense to curl | sh.
- rakoo 12y agoIt's interesting to note that we essentially do the same with javascript in the browser, except the user doesn't even know there's some code that is automatically run. The big difference, of course, being that javascript code runs in a sandboxed environment. Maybe we should create some kind of sandboxed sh ? (I actually hardly believe it will ever take on, seeing that so many sites tell you to run not `sh` but `sudo sh`... yeah, sure, why have unprivileged users, we should do everything as root anyway)
- paulmd 12y agoWell, the Unix approach to this is a sandbox application and a shell application, not a sandboxed shell application. Docker attempts many of those tasks. On windows there's Sandboxie, which does more or less what you want as well. It creates a sandbox whose filesystem and internals can be modified by sandboxed applications without affecting the state of the REAL filesystem. Very nice utility for mitigating bad programming - I often use it to run multiple copies of applications that crash or refuse to launch multiple instances.
- youngun 12y agoThe proper alternative is some sort of lightweight virtualization like Docker, with a proper security policy in place. You can mostly do this today curl <blah> | docker run --rm -t -i ubuntu sh but the containerizing naturally locks down/virtualizes some stuff you might want the script to be doing, like installing stuff locally. I think cleaning this up and making it friendly enough is a solvable UX problem, but I haven't quite solved it yet.
- razzaj 12y agoI don't see how this is less secure than downloading a program and running it. Or downloading some package that asks you to run an install script. People will see no problem with curl | sh as long as they feel they can trust the source/site asking them to do so. They will be running the same risk as with downloading binaries or install packages.
- Gigablah 12y agoExactly. This is little more than cargo culting.
- andrewchambers 12y agoI'd at least save the script somewhere so i can audit it if something goes wrong after i run it.
- dllthomas 12y agoThe truncation issue is an interesting additional wrinkle, if unlikely. I agree that, aside from that issue, the practice of many people is not materially worse than "curl | sh", but we should condemn that similarly.
- new299 12y agoIt's obviously somewhat prone to failure, as the script can't possibly work in every environment. But other than that as long as it's over https is there a security issue? Obviously, a better alternative is a package manager, pulling from a repository for which you have gpg keys installed (such as Debian provides). But that's not always an option. Even checking out a git repository and building from source seems as bad a curl | sh to me.
- zimbatm 12y agoBoth curl|sh and git checkouts tend to end up in production deploys so it's interesting to compare them. Both introduce a point of failure if the remote host becomes unavailable and you need to deploy new machines. The curl|sh method is vulnerable to change from the maintainer or any attacker who gets access to the storage layer. git is also vulnerable but requires a collision attack on SHA-1.
- new299 12y agoIf you're running it in production then that's a problem. But I'd dare say that relying on an external "apt-get install xxx" is pretty bad practice in production (to deploy new machines).
- zimbatm 12y agoI agree but most companies I know don't have the infrastructure or best-practices in place to avoid it. Copy-pasting the curl|sh is very low effort and will predictably end up in deploy code (if you have any).
- pritambaral 12y agoIf a git clone from github fails, I can still git clone from the last production machine I successfully cloned to.
- pritambaral 12y agoIf a git clone from github fails, I can still git clone from the last production machine I successfully cloned to. But this would be no different than curl -o installer.sh; rsync installer.sh; ssh remote@server 'sh installer.sh'; Mismatched SHA-1s are only noticeable when you have one to compare against. A git clone is always fresh, so if the attacker rewrote history, you'd not be warned.
- brian_c 12y ago`curl ... | sh` installations don't really bother me. The scripts tend to be short and commented, or at least readable. Sure beats running an opaque .pkg installer, which invariably asks for your password (presumably for no reason) and installs god-knows-what all over your hard drive.
- Slackwise 12y agoGenerally, yes, but some package managers have code-signing support, which means if you trust the authors, you can avoid potential hijacks. At the end of the day, though, you're always going to trust someone with something.
- deleted 12y ago[deleted]
- jammycakes 12y agoYes, but if you're doing curl ... | sh then you're not vetting the script you're running before you run it. If you were, you'd be running curl and sh as separate commands.
- tucosan 12y agoWhat I do is simply copy the `curl foo | sh` oneliner into a text editor which does not run in a shell, and then copy the line from there into the console. This does not save you from downloading the script and actually auditing that it does what it should.
- tomp 12y agoMost of these are downloading stuff over https, and sometimes from GitHub, so it really offers superior security to most AppStores and (signed) installers (as you can even look at the source, if you want to).
- sarciszewski 12y ago"superior security"? If I can hack the endpoint (or the server that handles the 301 redirect to github), game over.
- facepalm 12y agoThat goes for every software you install. The only solution is to not install any software. And then hope that the preinstalled software on your device is OK:
- sarciszewski 12y agoOR I could verify an asymmetric cryptographic signature based on a public key I already possess. As long as the private key is not stolen, an attacker who can breach the server cannot backdoor the software I'm downloading.
- facepalm 12y agoHow do you get the public key? I've heard the ssl certificate system that ships with browsers is broken, too. Maybe it would be an improvement to create a small command line tool that ensures https connections and asks for a hash before running a script?
- sarciszewski 12y agoKey management is out of scope for this discussion. Ideally, it's shipped with your OS. If your OS is insecure, you're already vulnerable.
- sarciszewski 12y agohttps://github.com/composer/getcomposer.org/issues/76 https://github.com/composer/getcomposer.org/issues/76
- bqe 12y agoMy thing with piping curl to a shell was always that a severed connection will run a partial script, which can have weird consequences. I wrote about it awhile back: http://blog.seancassidy.me/dont-pipe-to-your-shell.html http://blog.seancassidy.me/dont-pipe-to-your-shell.html
- Igglyboo 12y agoWould something like curl http://google.com/keylogger.sh > temp.sh && sh temp.sh work?
- sarciszewski 12y agoMore like: curl http://google.com/keylogger.sh http://google.com/keylogger.sh > temp.sh less temp.sh # actually read the fucking thing sh temp.sh rm temp.sh
- edwintorok 12y agoI'd also check at least the size, and checksum/GPG signature if available.
- dllthomas 12y agoIt avoids that particular problem, yes. It is still inadvisable to do it over http, and checking a digital signature might be even better. Looking at the results might be better still if you have the expertise, though at that point it is more or less isomorphic what everyone happily does in trusting repositories, make files in signed source tarballs, and similar.
- jordanpg 12y agoI sense that the reason these kinds of things are growing in popularity is that there is a command-line renaissance occurring among certains kinds of developers. I'm guessing that about half of these pages are used principally by Ruby/Rails crowds, for example. This is a natural outgrowth of Rails itself which expects even the novice dev to do everything from the CLI. I also notice a certain amount of machismo surrounding this sort of thing, which means that the novices are that much more likely to blindly install things, in spite of the more senior devs blandly insisting that they should "read and understand the script before running it." This is ironic because of course they are novices and learning how to do a security audit on a random bash script is a non-trivial affair, to put it most charitably. It's also ironic because Rails is supposed to be all about easy and convention, not auditing everything for oneself. The designers of OSs did not have in mind non-experts using the CLI with su turned on (or even off) all the time. In fact, user-friendly OSs are designed to prevent non-experts from doing any damage, anywhere. In all, it seems like this sort of thing is circumventing basic protections provided by experts for non-experts, and that is probably not something to encourage.
- crusso 12y ago1. These script-based solutions generally work across a variety of platforms where compiled executables would need to be customized. 2. They give an easy way to automatically download and install a tool in one pasteable command without having to manage downloads and deal with the inevitable extra UI of installer executables. 3. Why does one need to understand what a script is doing any more than one needs to understand what a downloaded installer executable is doing? At least with the shell scripts it seems like more of an option.
- fat0wl 12y agowhen I switched from RoR to Java I started to really understand these issues... with RoR I was using lots of open source code (how can someone be expected to read/comprehend all the code in c++ extension modules as well as a mound of Ruby?). I'm not sure what c++ extensions are actually capable of but it just seems like a scary thought to be able to hook this deeply into the system. Personally I wouldn't want to use a lib that invokes some c++ unless it is from a REALLY reliable source. So yeah the reason I bring up Java is I think there is strength in the notion of the "App Server" in the java world. It's like a partner for the OS that allows for somewhat of a security "air-lock". Even if using Docker or something to scale RoR / simulate the effect of an app server node, I just fundamentally think an OS has too much power.... a web app shouldn't have any access to it basically, except through known/monitored/regulated protocols and points of access. Basically, data can be handed to an "App server process" which in turn does some low-levelish system tasks, but the app itself can't do them. Personally I think the app server approach also makes deployments/scaling easier and reduces the need for a sysadmin guru. RoR shops (and languages that follow a similar paradigm) really shouldn't be running any apps that handle sensitive info for example without a Linux guru and a senior Rails dev auditing app modules (or at least keeping up-to-date on existing security audits). It's weird, those first few months of Java when you realize how limited you are by your EE or whatever type of container -- then it starts to feel natural/healthy. When architected properly, I don't think apps will ever suffer from this lack of freedom.
- mping 12y agoI normally do a curl | less before doing a curl | sh and take a quick peek. Not perfect, but at least it's a step in the right way. Like someone says, it's a matter of trust (but verify).
- sarciszewski 12y agoRace condition. :) Save it to disk, examine, then run.
- coriny 12y agoAs already mentioned, save to disk first to avoid network connection failures messing you up. To avoid an extra command use "tee" to output to file while viewing it (i.e. it's "less" and ">" functionality combined).
- dllthomas 12y ago'To avoid an extra command use "tee" to output to file while viewing it (i.e. it's "less" and ">" functionality combined).' That's undesirable. First, because you should be making the decision about whether to run the script after you look at it, and if it's already running while you read it then it's probably too late. Second, because you should not be echoing possibly-malicious characters to the terminal - view with less or an editor, tee works like cat here.
- coriny 12y ago"First, because you should be making the decision about whether to run the script after you look at it" - exactly, which is what my suggestion is. All I'm suggesting with tee is that it allows you to read in terminal what you are writing to file in the same command. The OP was downloading the script to view in less, and then downloading it again to execute. This method at least ensures that what you view is what you are going to execute but ... "Second, because you should not be echoing possibly-malicious characters to the terminal" - this is something I know nothing about, so I would be (and maybe others) highly appreciative of any links about this class of attacks that you could post. Is it possible to execute malicious code while writing to STDOUT, or is it because you can hide malicious code with escape characters? Also, I don't quite understand the "cat" comment as we're not doing any file concatenation here?
- tptacek 12y agoPreviously: https://news.ycombinator.com/item?id=2420509 https://news.ycombinator.com/item?id=2420509 Nate Lawson's comment in particular.
- sarciszewski 12y agohttps://news.ycombinator.com/item?id=2421012 https://news.ycombinator.com/item?id=2421012 Sadly, it had become more popular since you posted that comment.
- andrewchambers 12y agoI think not saving the script somewhere first makes it worse, You can't go back and inspect what it has actually done in the worst case scenario. To install rust the other day and had to read the whole script to be sure.
- mdhgriffiths 12y agoWhat's the worst that could happen? It's only PHP. https://apigility.org/ https://apigility.org/