
curl | sh - lelf
http://curlpipesh.tumblr.com/
======
TeeWEE
Note 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.

~~~
cowabunga
No it's not because MSI packages and EXEs are signed so there is at least a
chain of trust. SmartScreen kicks you in the face if it's not "known" by
various metrics and it's hard to get around that these days (as someone who
just had to get EV certs for their MSI). If you click through that, and you
don't know what the source was then you're a muppet.

curl + bash is suck and blam the machine. Hope you didn't do a sudo in the
last few seconds...

[http://www.nastybastard.com/funky-super-
installer.sh](http://www.nastybastard.com/funky-super-installer.sh):

    
    
       #!/bin/bash
       echo "mwuhahahaha"
       sudo rm -rf /boot

~~~
maccard
> No it's not because MSI packages and EXEs are signed

Sure, some are. But most software packages that a user is going to download
aren't signed.

~~~
mooreds
Right. And really, who checks signatures?

I'm a developer and I don't think I've every checked an md5 signature of a
jarfile/gem/package I've downloaded. Nor have I ever been in an environment
where that was ever mentioned. (Have mostly worked in small to medium
businesses--I imagine that bigger orgs or the defense department might do
this.)

------
jordanpg
I 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
1\. 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.

------
razzaj
I 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
Exactly. This is little more than cargo culting.

~~~
andrewchambers
I'd at least save the script somewhere so i can audit it if something goes
wrong after i run it.

------
dozzie
Yeah. 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.

------
tptacek
Previously:

[https://news.ycombinator.com/item?id=2420509](https://news.ycombinator.com/item?id=2420509)

Nate Lawson's comment in particular.

~~~
sarciszewski
[https://news.ycombinator.com/item?id=2421012](https://news.ycombinator.com/item?id=2421012)

Sadly, it had become more popular since you posted that comment.

------
bqe
My 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
Would something like

    
    
        curl http://google.com/keylogger.sh > temp.sh && sh temp.sh
    

work?

~~~
sarciszewski
More 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

~~~
Igglyboo
Somewhat inexperienced with linux/unix. What's the purpose of "less temp.sh"
here?

~~~
dllthomas
less is to view the file. It is interactive and safer than cat - the latter
because less (by default) strips out terminal control characters.

------
sveredov
Here is another curlpipesh: [https://fixubuntu.com/](https://fixubuntu.com/)

~~~
sarciszewski
Except, that one shows the full source so you can copy, paste, review, and
save it instead.

~~~
ToastyMallows
You can do that for all of these, just request the file directly and copy it
out of the browser.

------
new299
It'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
Both 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
If 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
I 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).

------
brian_c
`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
Generally, 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.

------
TimWolla
At least most of the examples are using https.

~~~
sarciszewski
Mojolicio.us is a good counter-example. Unfortunately, they're not on the
Tumblr yet.

~~~
marcusramberg
Unfortunately 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/)

------
tucosan
What 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.

------
andrewchambers
I 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.

------
tomp
Most 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
"superior security"?

If I can hack the endpoint (or the server that handles the 301 redirect to
github), game over.

~~~
facepalm
That 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
OR

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.

~~~
tomp
Which is exactly the same as you verifying the public HTTPS key of the server
you're downloading the software from; in reality, the only thing that differs
is the server you're targeting (the compilation server, v.s. the downloading
server).

~~~
dllthomas
The downloading server is necessarily public facing, and the key is
necessarily unlocked during operation. In a sense that's a difference in "the
server you're targeting", but both are points in favor of pushing that to the
compilation server.

------
mping
I 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).

~~~
coriny
As 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
_' 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
"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?

~~~
dllthomas
_" 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."_

Gotcha. That makes more sense.

Regarding the second, I don't know whether there are presently any attacks in
the wild for any commonly deployed setups (if anyone else does, I'd love to
hear about them) but terminals are incredibly messy beasts once you start to
throw nonprintable characters at them. Better not to expose that surface area.

------
sarciszewski
[https://github.com/composer/getcomposer.org/issues/76](https://github.com/composer/getcomposer.org/issues/76)

------
mdhgriffiths
What's the worst that could happen? It's only PHP.
[https://apigility.org/](https://apigility.org/)

