Hacker News Reader

Comment by dwheeler | Hacker News Reader

Um, no. Curl-to-shell is bad.

Check this out: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

As the author notes:

> You’re not running some random shell script from a random author, you’re running it from a software vendor who you already trust to run software.

Without any form of validation that the shell script I'm running is actually from the software vendor in question. That trust is even further stretched when the request is 301 redirected to another host entirely.

Between custom domain names, TLDs, Let's Encrypt (I love Let's Encrypt, but it provides is encryption, not trust) and cheeky developers using combinations of those, how can I really know that a script coming from (fictional example) https://install.dock.er is actually the Docker company?

The same arguments apply for downloading a binary.

If you want to pull this even further. When is the last time you verified the signing keys of your OS distribution repo without relying on the internet?

A lot of install methods that are not curl/sh are like: here copy this bash line to add apt GPG keys for our repo, apt update and install. A lot of people don't bother to check those keys.

True, some people don't check those keys, but it's possible to do. There's a well trodden (and cryptographically secure) path for gaining trust in a key that's distinct from downloading and unpackaging a file.

This is (currently) not possible to do with scripts downloaded from a web page. Especially when immediately piped into a shell.

As with most issues in security its a balance between usability and security. The real problem is the majority of the users will always try to find the path of least resistance. No matter how well documented a secure procedure is, if a user can find a oneliner they will use it instead.

I've seen this in other places as well. Vendor makes a comprehensive guide. Some people condense that to a minimum and will even boast they "made" an easier way to do X or Z, whilst ommiting all the caveats. Of course that will become the popular 'standard' people find. And they'll go complain to the vendor if it doesn't work without even reading the original instructions.

You're not wrong with your first paragraph. That doesn't make the use of curl|sh good however. It doesn't justify developers laziness in eschewing secure methods of distribution, or writing articles like this that justify that same laziness.

Wrong. You are trusting much more than that, including network components outside of your control and the author's.

Plus you are pushing forward the bad pattern and being part of the problem.

You are encouraging other authors and users to do the same.

Tell me how this is different for downloading a binary instead. Unless you get something like a GPG through a completely different channel.

A major point of the article is that there's nothing unique about curl-to-shell which enables this exploit; it would be equally easy to perform it with a fully-signed and checksummed binary downloaded through a secure channel.

That major point is plain wrong.

https://sysdig.com/blog/friends-dont-let-friends-curl-bash/

https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

These attacks can be mounted on the network side.

Also you can inadvertently execute data from a benign captive portal or a server error page and so on.

I can do similar attacks on ANYTHING in the form of grabbing code and running it on my machine.. If you aren't doing 'curl | bash' recklessly it isn't a problem.

You do need to control both the key and the channel in this case.

Did you not read the article? He addresses those points for the most part. The primary idea is that when you run ANY SOFTWARE in reality you have no clue what it might do, you didn't look through every single line of code. There is nothing wrong with 'curl .. | sh' as long as you're running a script completely blind.

"Compared to running with razor blades, running with scissors is fine," is not much of a justification of an activity.

Instead of providing justifications, perhaps we should focus on education (or making it simpler to be secure)?

If you don’t actually read or verify the script this doesn’t matter. If you cant trust the server you probably shouldn’t run any code from it.

How does one trust a server? What assurances can any server provide that they are who they say they are?

x509 certificates certainly don't provide those assurances.

No no no, human trust, not machine/cryptographic trust. The same way you have human trust (or distrust) over many things running on your computer. You didn’t get to verify any of the code in the firmware either.

There’s differing levels of paranoia. I don’t pipe curl to shell at work. I do it at home sometimes, usually via Github.

But you can trust the large userbase of a popular Linux distribuiton, especially when big companies use it.

Distro package managers have other advantages than trust. Typically they at least verify cryptographic hashes but many of them also verify public key signatures as well.

This is why its safe to download packages from mirrors.

With that having been said, Debian takes an extra step into the absurd by using plain HTTP with no TLS for downloading packages. There’s no obvious security issue with that, but it does feel like a bad decision, since anyone in your request path can see what software you’re installing, and if there ever were a vulnerability it would be much easier to exploit due to the lack of security at the transport layer.

Reply on news.ycombinator.com