Evil cURL|Bash?

Thu, Sep 20, 2018

Most of us will have seen this installation method, using any kind of commandline download helper outputting the content of a file originating from the internet to STDOUT and then piping it to a shell. Simple example:

curl https://cmdline.nl/vim/bootstrap.sh | bash

Now, this way of installing anything most probably derived from the fact that your standard Linux package managers are always a couple steps behind cutting edge, and cURL|Bash is just an easy, quick way of getting stuff installed on your machine, VM, remote compute instance, container etc. Many vendors offer this type of installation, examples are Kubernetes, Docker (get.docker.io seems obsolete nowadays), GitLab, SaltStack (although have switched to a download-first, then run in shell), Sysdig, RVM, Sandstorm and many more.

I always thought it was fishy by the looks of it, a while back i hardly ever installed anything outside of a package manager (nothing beats apt), with which downloaded packages and dependencies are checksummed before installation, and the packages are also checked if they were actually signed with the correct GPG key, the GPG key of which the public parts are stored in the keyring of the local root user. The cryptographic verification makes it safe to actually use the remote repositories as plain HTTP, see for example Debian’s sources.list.

Going back to the cURL|Bash method, many people have serious concerns about it, there’s even a Hall of shame dedicated to this installation method. Now why and what could possibly go wrong?

MITM attack?

Well let’s keep it simple for now and say just make sure the connection is over TLS

Stream may break (or be broken by an attacker) and the script may break at a crucial point

That’s easy to avoid by wrapping everything in a function that’s only called at the end, e.g.:

function main() {

    echo "here we go"
    ...
}

main
exit $?

Running an unknown script and piping right into a local shell, it could contain dangerous commands

Sure. But would you normally download it (you could) and read every line of code before you execute? Does anyone download any software and analyze what it does exactly, besides security researchers? What about compiled executables or .deb or .rpm packages. Besides that, downloading a script first does not guarantee anything just yet, server-sided it’s no rocket science to detect whether or not we’re being piped to a shell or not

The installer wasn’t signed

Good and only valid point IMHO. There’s no way to cryptographically verify that the code you’re running was authored by whoever you trust more than the server you’re connecting to. Worth mentioning though is that pipethis on GitHub actually makes an effort to solve that part.

So?

Bottom line, it all comes down to trust. If you don’t know whether you can trust the vendor and their servers that offer a cURL|Bash way of installing, you shouldn’t and stick with repositories that contain packages that are signed (hopefully offline) by maintainers affiliated with the product you want to install.

However…

Just blindly downloading GPG keys for additional repositories from the same remote location and importing those in your trusted keyring is really the same difference - how do you know that actually is the correct key? All comes back to trust again, unless there’s a way to verify the key centralized. For all you know you’re downloading a key from an attacker, who also signed the packages in that repository and there you go… you install a shiny new package and some crafted hooks in the package run as root. Verified and all. I guess to that extent, a cURL|Bash is far from ideal, but no worse (or better) than various other ways to get software installed…