this post was submitted on 13 Mar 2025
275 points (96.6% liked)

Linux

7395 readers
295 users here now

A community for everything relating to the GNU/Linux operating system

Also check out:

Original icon base courtesy of [email protected] and The GIMP

founded 2 years ago
MODERATORS
 

curl https://some-url/ | sh

I see this all over the place nowadays, even in communities that, I would think, should be security conscious. How is that safe? What's stopping the downloaded script from wiping my home directory? If you use this, how can you feel comfortable?

I understand that we have the same problems with the installed application, even if it was downloaded and installed manually. But I feel the bar for making a mistake in a shell script is much lower than in whatever language the main application is written. Don't we have something better than "sh" for this? Something with less power to do harm?

(page 3) 50 comments
sorted by: hot top controversial new old
[–] [email protected] 19 points 2 months ago (1 children)
[–] [email protected] 8 points 2 months ago (2 children)

Download it and then read it. Curl has a different user agent than web browsers.

load more comments (2 replies)
[–] [email protected] 3 points 2 months ago

Just use a VM or container for installing software. It can go horribly wrong in a isolated place.

[–] [email protected] 2 points 2 months ago (1 children)

I also feel incredibly uncomfortable with this. Ultimately it comes down to if you trust the application or not. If you do then this isn't really a problem as regardless they're getting code execution on your machine. If you don't, well then don't install the application. In general I don't like installing applications that aren't from my distro's official repositories but mostly because I like knowing at least they trust it and think it's safe, as opposed to any software that isn't which is more of an unknown.

Also it's unlikely for the script to be malicious if the application is not. Further, I'm not sure a manual install really protects anyone from anything. Inexperienced users will go through great lengths and jump through some impressive hoops to try and make something work, to their own detriment sometimes. My favorite example of this is the LTT Linux challenge. apt did EVERYTHING it could think to do to alert that the steam package was broken and he probably didn't want to install it, and instead of reading the error he just blindly typed out the confirmation statement. Nothing will save a user from ruining their system if they're bound and determined to do something.

[–] [email protected] 2 points 2 months ago (1 children)

In this case apt should have failed gracefully. There is no reason for it to continue if a package is broken. If you want to force a broken package, that can be it's own argument.

[–] [email protected] 2 points 2 months ago

I'm not sure that would've made a difference. It already makes you go out of your way to force a broken package. This has been discussed in places before but the simple fact of the matter is a user that doesn't understand what they're doing will perservere. Putting up barriers is a good thing to do to protect users, spending all your time and effort to cover every edge case is a waste of time because users will find ways to shoot themselves in the foot.

[–] [email protected] -1 points 2 months ago (1 children)

I understand that we have the same problems with the installed application, even if it was downloaded and installed manually. But I feel the bar for making a mistake in a shell script is much lower than in whatever language the main application is written.

So you are concerned with security, but you understand that there aren't actually any security concerns... and actually you're worried about coding mistakes in shitty Bash?

[–] [email protected] 1 points 2 months ago (1 children)

cd /some/dir && rm -rf *

I've seen this in a script before

load more comments (1 replies)
[–] [email protected] 22 points 2 months ago (5 children)

I think safer approach is to:

  1. Download the script first, review its contents, and then execute.
  2. Ensure the URL uses HTTPS to reduce the risk of man-in-the-middle attacks
[–] [email protected] 6 points 2 months ago (10 children)

Install scripts are bad in general. ideally use officially packaged software.

load more comments (10 replies)
[–] [email protected] 14 points 2 months ago (1 children)

If you've downloaded and audited the script, there's no reason to pipe it from curl to sh, just run it. No https necessary.

[–] [email protected] 1 points 2 months ago (3 children)

The https is to cover the factthat you might have missed something.

I guess I download and skim out of principle, but they might have hidden something in there.

load more comments (3 replies)
load more comments (3 replies)
[–] [email protected] 15 points 2 months ago (4 children)

Unpopular opinion, these are handy for quickly installing in a new vm or container (usually throwaway) where one don't have to think much unless the script breaks. People don't install thing on host or production multiple times, so anything installed there is usually vetted and most of the times from trusted sources like distro repos.

For normal threat model, it is not much different from downloading compiled binary from somewhere other than well trusted repos. Windows software ecosystem is famously infamous for exactly the same but it sticks around still.

load more comments (4 replies)
[–] [email protected] 2 points 2 months ago

Just direct it into a file, read the script, and run it if you're happy. It's just a shorthand that doesn't require saving the script that will only be used once.

[–] [email protected] 4 points 2 months ago

I usually just take a look at the code with a get request. Then if it looks good, then run manually. Most of the time, it's fine. Sometimes there's something that would break something on the system.

I haven't seen anything explicitly nefarious, but it's better to be safe than sorry.

[–] [email protected] 7 points 2 months ago

curl | sudo bash Gang

[–] [email protected] 21 points 2 months ago (2 children)

You shouldn't install software from someone you don't trust anyway because even if the installation process is save, the software itself can do whatever it has permission to.

"So if you trust their software, why not their install script?" you might ask. Well, it is detectable on server side, if you download the script or pipe it into a shell. So even if the vendor it trustworthy, there could be a malicious middle man, that gives you the original and harmless script, when you download it, and serves you a malicious one when you pipe it into your shell.

And I think this is not obvious and very scary.

[–] [email protected] 0 points 2 months ago* (last edited 2 months ago) (1 children)

it is detectable on server side, if you download the script or pipe it into a shell

Irrelevant. This is just an excuse people use to try and win the argument after it is pointed out to them that there's actually no security issue with curl | bash.

It's waaaay easier to hide malicious code in a binary than it is in a Bash script.

You can still see the "hidden" shell script that is served for Bash - just pipe it through tee and then into Bash.

Can anyone even find one single instance of that trick ever actually being used in the wild (not as a demo)?

[–] [email protected] 5 points 2 months ago

I never tried to win any argument. Hell I was not even aware that I'm participating in one. I just wanted to share the info, that even if the vendor is absolutely trustworthy and even if you validated the script by downloading and looking at it, there's still another hole that's not obvious to see.

Yes it's unlikely, but again, I never said it were. There are also arguments you can run curl with, to tell it to do the download first and then push it through the pipe afterwards, though I don't know them by heart now.

It won't cost you anything to set those parameters, when you insist to use curl | bash, just in the off chance that someone's trying to do what I mentioned.

But I'm also someone who usually validates their downloads with a checksum so maybe I'm just weird. Who knows.

[–] [email protected] 7 points 2 months ago (1 children)

it is detectable [...] server side, if you download the script [vs] pipe it into a shell

I presume you mean if you download the script in a browser, vs using curl to retrieve it, where presumably you are piping it to a shell. Because yeah, the user agent is going to reveal which tool downloaded it, of course. You can use curl to simply retrieve the file without executing it though.

Or are you suggesting that curl makes something different in its request to the server for the file, depending on whether it is saving the file to disk vs streaming it to a pipe?

[–] [email protected] 11 points 2 months ago (1 children)

It is actually a passive detection based of the timing of the chunk requests. Because curl by default will only request new chunks when the buffer is freed by the shell executing the given commands. This then can be used to detect that someone is not merely downloading but simultaneously executing it. Here's a writeup about it:

https://web.archive.org/web/20250209133823/https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/

You can also find some proof-of-concept implementations online to try it out yourself.

[–] [email protected] 4 points 2 months ago (1 children)

Wow, thanks for this. That is very helpful context. And thanks for your original post too, or I'd never have asked.

[–] [email protected] 2 points 2 months ago

Oh, you're welcome, kind person :)

[–] [email protected] 17 points 2 months ago* (last edited 2 months ago) (1 children)

It's not much different from downloading and compiling source code, in terms of risk. A typo in the code could easily wipe home or something like that.

Obviously the package manager repo for your distro is the best option because there's another layer of checking (in theory), but very often things aren't in the repos.

The solution really is just backups and snapshots, there are a million ways to lose files or corrupt them.

[–] [email protected] 0 points 2 months ago (3 children)

You should use officially packaged software. That's the safest option.

load more comments (3 replies)
[–] [email protected] 10 points 2 months ago

Those just don't get installed. I refuse to install stuff that way. It's to reminiscent of installing stuff on windows. "Pssst, hey bud, want to run this totally safe executable on your PC? It won't do anything bad. Pinky promise". Ain't happening.

The only exception I make is for nix on non-nixos machines because thwt bootstraps everything and I've read that script a few times.

Anti Commercial-AI license

[–] [email protected] 7 points 2 months ago

How is that safe?

It's not, it's a sign that the authors don't take security seriously.

If you use this

I never do.

[–] [email protected] 1 points 2 months ago (2 children)

Am I the only one who cringes when I have to update my system?

How do I know the maintainers of the repo haven't gone rogue and are now distributing malware?

DAE get anxious when running code on computer?

I think for the sake of security we should just use rocks, stones, and such to destroy all computers, as this would prevent malicious software from being executed.

[–] [email protected] 6 points 2 months ago (1 children)

How do I know the maintainers of the repo haven't gone rogue and are now distributing malware?

Depends on the repo but at least for Debian, there's a path of trust between GPG keys I've signed and the Debian release GPG keys.

[–] [email protected] 0 points 2 months ago (1 children)

How do you know that the malware goblin hasn't installed malware on your computer when you weren't looking?

I think the only foolproof plan is using boulders, stones, and perhaps other blunt objects to deal with the issue of code executing altogether.

[–] [email protected] 2 points 2 months ago (1 children)

What are you trying to say?

load more comments (1 replies)
load more comments (1 replies)
[–] [email protected] 7 points 2 months ago* (last edited 2 months ago) (1 children)

What's stopping the downloaded script from wiping my home directory? If you use this, how can you feel comfortable?

You're not wrong, but there's an element of trust in anything like this and it's all about your comfort level. How can you truly trust any code you didn't write and complie yourself. Actually, how do you trust the compiler.

And let's be honest, even if you trust my code implicitly (Hey, I'm a bofh, what could go wrong?) then that simply means that you're trusting me not to do anything malicious to your system.

Even if your trust is well-placed in that regard, I don't need to be malicious to wipe your system or introduce a configuation error that makes you vulnerable to others, it's perfectly possible to do all that by just being incompetent. Or even being a normally competent person who was just having a bad day while writing the script you're running now. Ooops.

load more comments (1 replies)
[–] [email protected] 1 points 2 months ago (1 children)

Absolutely. Wanted to try out the famous Python management tool UV last week, installation instruction is like this:

curl -LsSf https://astral.sh/uv/install.sh | sh

Yeah, no thank you.

load more comments (1 replies)
load more comments
view more: ‹ prev next ›