A curated list of questionable installation instructions | Hacker News Reader

A curated list of questionable installation instructions

curlsh.com

15 pointsstabbles17 comments

For those saying curl | sh isn't that bad, remember that the codecov script was breached, and attackers used it to upload environment variables containing secrets, and it took months to get noticed [1].

If they had provided a versioned URL and checksum validation as part of their copy & paste snippet, the breach would have been noticed right away.

[1] https://www.reuters.com/technology/codecov-hackers-breached-...

See: https://www.arp242.net/curl-to-sh.html

This 1000 times

This is true when the install script is indeed from a source you ‘trust’ but there are also sites that aggregate many apps into ‘one install script’ or I have seen StackOverflow answers list these types of install command to install a missing dependency. I personally wouldn’t be too quick to just trust those.

Yes. But a one-line install script is easily auditable. I mean, the URL you are fetching and executing from is in your face. Validate URL, consider your trust - that's all. It's the same what we've been taught before we enter credentials within any site: validate domain.

No, you need to verify the application itself too.

That's the major problem with these scripts, you rely on the web server not having been compromised, the release builder not having been compromised and you not being MITMed. Now, someone might inject nasty changes into a code repository, but it tends to be harder.

It's fairly easy (trivial) to serve a different install script to a full web browser than to curl.

That's just one of the problems, but I'd say it's the main one. If you truly trust the creator with install power, download the script yourself with curl/wget/whatever, have a glance if it's what you expect, and fire away.

I know this is considered a bad practice - but how is it worse than downloading it first and then running it? It's only better if someone is going to inspect the script before running it and how many people actually do that? Or will do it if they were forced to?

Optimally, you want to download software from a static, external source that people can vet, preferably protected from tampering with digital signatures. For most of these scripts, there's no way to know if the file you'll receive will be the same as a file someone with an interest in installer security will receive. You'd have to download from a source that you can believe to be reasonably static to get the minimum amount of trust at the least.

It's trivial to serve different files to different user agents, and with terminal escape codes you could even hide malicious code from the few people that cat these scripts. I don't like downloading files from a project's own, potentially dynamic, server, and executing them directly, even though that's commonly the only way to run certain tools.

In my opinion, downloading github release files or even just the scripts from github directly is worse than using reliable repositories with signatures and all that, but better than downloading random shell or exe files and executing them as admin. You'll always be at some kind of risk of software manipulation, so you have to choose how much risk you want to accept when it comes to this stuff.

Technically GitHub releases can be signed, but even then you're trusting the release build bot most of the time...

What I find particularly weird about rustup is their hard coding of TLS 1.2. Does their website not offer TLS 1.3? Is this protection against outdated clients that still default to TLS 1.0 or below?

I think the miniconda example isn't as bad, because you have the opportunity to inspect the script between the commands if you're curious. You'll have to be wary of obfuscation tricks, but at least it's not the direct equivalent of opening a telnet session to a remote server.

MITM protection maybe? Also it's 1.2 or greater:

  > curl --help all|grep tlsv1.2
       --tlsv1.2       Use TLSv1.2 or greater

One option is to trust on first use, checksum the installation script and at least casually verify the diff each time the checksum changes[1].

Pros:

- Protects against simple hijacking.

- Reproducible as long as the installer doesn't also call out to a moving target, such as example.com/releases/latest.

Cons:

- Build breaks as soon as the installer is bumped. If it's bumped often (or just before an important release) this can cause pain.

- TOFU may not be acceptable, but of course you could review the code thoroughly before even the first use.

- The review of each version could be non-trivial. Usually installers are pretty simple and stable though, YMMV.

[1] https://github.com/linz/geostore/blob/b3cd162605109da8a3a688...

Right because homebrew, a package manager that could potentially insert arbitrary code into your packages is somehow far more secure when installed by clicking a download button and running a GUI wrapping basically the same script?

The problem is there's no universal way to install software across platforms in a secure way.

The closest I've seen is running exes with docker run. Then at least I can somewhat control how much access the exe has to my machine.

Download a signed repository, verify it (including some code check) and build yourself.

It's fewer steps than trusting also some package maintainer or build bot to not be compromised.

Not trusting the software at all is the only real solution. The only operating system that makes that practical is Qubes OS.

One can always manage a lot of VM's manually, but that's complicated enough that one usually only bothers for very specific software, and not everything like what is done in Qubes OS.

Reply on news.ycombinator.com