Live data from Hacker News

curl | sh

curlpipesh.tumblr.com

61–70 of 115 posts

Re: curl | sh

#61

Earlier quoted context omitted.

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

More like: curl http://google.com/keylogger.sh > temp.sh less temp.sh # actually read the fucking thing sh temp.sh rm temp.sh

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

Re: curl | sh

#62

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.

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

Re: curl | sh

#63

Earlier quoted context omitted.

More like: curl http://google.com/keylogger.sh > temp.sh less temp.sh # actually read the fucking thing sh temp.sh rm temp.sh

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

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

Re: curl | sh

#64

Earlier quoted context omitted.

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?

Key management is out of scope for this discussion. Ideally, it's shipped with your OS. If your OS is insecure, you're already vulnerable.

Re: curl | sh

#65
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?

It 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.

Re: curl | sh

#66
post #62

Earlier quoted context omitted.

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.

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

The difference is that the private key is on the server that handles HTTPS requests. If the server gets owned, they can change stuff arbitrarily. Having an offline PGP key makes attacks more expensive.

Re: curl | sh

#67
post #58

Earlier quoted context omitted.

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.

Yes, I'm aware of how HTTP pipelining works. It was a poor choice of terminology. My point is that by default curl does buffer some of the response. And if the connection was terminated before the first buffer was output, then I would expect this to result in an error which would abort the shell pipeline.

Re: curl | sh

#68
post #5

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

Trust is really the only solution, we as developers might be able to inspect some code before we run it but if it is sufficiently complex we could spend months auditing it. Even worse for the non-technical users that can't tell a hello world from a keylogger, there really is no solution other than some trust based system.

Trust is a partial solution. You need to be able to make sure that you're only trusting those who are trustworthy. A part of that is assessment of trustworthiness, and a part is making sure you're aware who you're trusting (probably allowing delegation).

Re: curl | sh

#69
post #62

Earlier quoted context omitted.

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.

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

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.

Re: curl | sh

#70

Earlier quoted context omitted.

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.

Because you might be piping known stuff to them. Receiving a partial input stream is not necessarily reliant on networking.
Post reply on HN