Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

curl | sh

curlpipesh.tumblr.com

Post reply on HN
Print view View original

51–60 of 115 posts

Re: curl | sh

#51

Post by edwintorok »

oneeyedpigeon wrote: post #30
RKearney wrote: post #12

Earlier quoted context omitted.

I think one of the larger issues with curl | sh is what could happen in the event of a network outage or early termination on the connection. For example, if you're downloading a script that has a line like this rm -rf ~/.tmp/foo/bar But the HTTP connection was lost before the entire file was downloaded and `rm -rf ~` was the end of one packet and `/.tmp/foo/bar` was the contents of the other (lost) packet, you're sc…

Why don't shells NOT execute a command if there's no trailing EOL character, to mitigate this very problem?

Why should shells encourage this behaviour (piping unknown stuff to them?)

You should at least download, verify the size and checksum (if available), take a peek at it, and only then run it.

Re: curl | sh

#52

Post by michaelmior »

mikeash wrote: post #31
michaelmior wrote: post #26

Earlier quoted context omitted.

In at least some of those cases, I would expect curl to exit with an error and the pipeline to abort.

All bash sees are bytes coming in on stdin, and eventually an EOF. It neither knows nor cares what caused the EOF.

Sure, but if the server response is not pipelined (as is probably often the case), then bash should never see anything.

Re: curl | sh

#53

Post by sarciszewski »

peterwwillis wrote: post #49
sarciszewski wrote: post #29

Earlier quoted context omitted.

""" Personally, i'm totally comfortable with the idea of someone owning my box. The files I care about are backed up offline, I don't have many secrets, and the only accounts that would affect my life in general have passphrases, pins and multiple-factor auth tied to them. The worst thing someone could maybe do is impersonate me and cause havoc using my accounts, but I really don't see anyone having cause to do that.…

Uh, it's not an argument, it's my personal feelings and my personal opinions. It's OK if you don't feel the same way.

I look forward to you getting 0wned then. Just my personal feelings and personal opinions. :)

Re: curl | sh

#54

Post by edwintorok »

Igglyboo wrote: post #48
bqe wrote: post #35

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

Would something like curl http://google.com/keylogger.sh > temp.sh && sh temp.sh work?

I'd also check at least the size, and checksum/GPG signature if available.

Re: curl | sh

#55

Post by crusso »

jordanpg wrote: post #36

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 surrou…

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.

Re: curl | sh

#56

Post by michaelmior »

LeonidasXIV wrote: post #28
michaelmior wrote: post #26

Earlier quoted context omitted.

In at least some of those cases, I would expect curl to exit with an error and the pipeline to abort.

Some scripts also detect this and are written so that there is no code executed before the file is not complete. Of course, that's a minority.

Definitely including a checksum and validating that before executing would be ideal.

Re: curl | sh

#57

Post by sarciszewski »

idlewan wrote: post #46
sarciszewski wrote: post #23

Earlier quoted context omitted.

My preferred hypothetical installer Trojan method is to make it append a value to ~/.ssh/authorized_keys and then ping a C&C server with the current username and IP ;)

You would still have to hope that sshd is enabled and accepting connections (which by default it shouldn't, at least on end-user distros).

True. I've mostly seen PHP devs using this to deploy composer onto staging and production servers, so it would work on them. ;)

Re: curl | sh

#58

Post by mikeash »

michaelmior wrote: post #52
mikeash wrote: post #31

Earlier quoted context omitted.

All bash sees are bytes coming in on stdin, and eventually an EOF. It neither knows nor cares what caused the EOF.

Sure, but if the server response is not pipelined (as is probably often the case), then bash should never see anything.

HTTP pipelining is about reusing a TCP connection for multiple requests. It doesn't influence when curl outputs data and wouldn't apply here anyway. I don't think there's any mode which would cause curl to buffer the entire response before writing any of it.

Re: curl | sh

#59

Post by peterwwillis »

phaer wrote: post #37
peterwwillis wrote: post #17

Earlier quoted context omitted.

If you're really paranoid, download the MD5 and PGP keys of the application release's source code tarball from the author's website using SSL. Then unpack the source (being careful to use a sandbox, because an exploit in gzip/tar/etc might be bad) and examine the source code for any unexplained or dangerous behavior. Then compile and install it using a non-root user. Personally, i'm totally comfortable with the idea…

Who do you enter your passphrases, pins, etc if you box is controlled by someone else? How do you know there's no keylogger running? How do you use PGP if you don't care about the security of your private key?

I do assume there could be a keylogger. I'd enter a password into the computer, but passphrases would be spoken over the phone to a representative that I call, and pins are entered either over the phone or once I receive them from a 2FA source. I avoid using sensitive accounts online if I can do it over the phone or in person.

(part of why I want 2FA providers to verify an identity using two or more devices is so that if your workstation is compromised, it still couldn't complete the authentication without a secondary device, making mitm much more difficult; though obviously they could still hijack an existing connection on either device... a benefit would be that for example, an attacker couldn't use a hijacked connection to initiate a money transfer behind your back without having you confirm it on your mobile device as well)

If you are depending on PGP, and only install software from verified sources using secure connections, your private key is still secure. If you don't depend on PGP, you wouldn't care about the security of your private key. You could also do private key operations on an airgapped machine, which wouldn't depend on the security of your main workstation.

Re: curl | sh

#60

Post by facepalm »

sarciszewski wrote: post #45
facepalm wrote: post #34

Earlier quoted context omitted.

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:

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.

How 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?

Post reply on HN