173
A sneaky demonstration of the dangers of curl bash (blog.k3can.us)
submitted 8 months ago by to c/selfhosted@lemmy.world
70 comments fedilink hide all child comments
 

I set up a quick demonstration to show risks of curl|bash and how a bad-actor could potentially hide a malicious script that appears safe.

It's nothing new or groundbreaking, but I figure it never hurts to have another reminder.

you are viewing a single comment's thread
view the rest of the comments
[–] 60 points 8 months ago (26 children)

you’d have to be mad to willingly pipe a script to bash without checking it. holy shit

  • permalink
  • fedilink
  • source
  • hideshow 26 child comments
    •
  • [–] 31 points 8 months ago (2 children)

    And you better inspect and execute a downloaded copy, because a malicious actor can serve a different file for curl/wget than to your browser

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 21 points 8 months ago

    And it's wild how much even that has been absolutely normalized by all these shitty lazy developers and platforms. Vibe coding it just going to make it worse. All these programs that look nice on the surface and are just slop on the inside. It's going to be a mess.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 18 points 8 months ago (11 children)

    Is it different from running a bash script you downloaded without checking it? E.g. the installer that you get with GOG games?

    Genuine question, I'm no expert.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 11 child comments
    •
  • [–] 12 points 8 months ago (7 children)

    I have no problems with running scripts from the internet, AFTER you check them. Do NOT blindly run a script you found on the internet. As others have said download them, then check them, then and only then run them if they're safe. NEVER pipe to bash, ever.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 9 points 8 months ago (6 children)

    Ok but not everyone has that skill. And anyway, how is this different to running a binary where you can't check the code?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 11 points 8 months ago (5 children)

    it's exactly the same. Don't run binaries you don't trust fully. But i get what you mean. miley_cyrus_nude.jpg.exe is probably gonna end badly.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 6 points 8 months ago (4 children)

    Yeah I get that, but I would install docker, cloudflared, etc by piping a convenience script to bash without hesitation. I've already decided to install their binary, I don't see why the install script is any higher risk.

    I know it's a controversial thing for everyone to make their own call on, I just don't think the risk for a bash script is any higher than a binary.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 8 points 8 months ago* (1 child)

    I won't lie, I use curl | bash as well, but I do dislike it for two reasons:

    Firstly, it is much, much easier to compromise the website hosting than the binary itself, usually. Distributed binaries are usually signed by multiple keys from multiple servers, resulting in them being highly resistant to tampering. Reproducible builds (two users compiling a program get the same output) make it trivial to detect tampering as well.

    On the other hand, websites hosting infrastructure is generally nowhere near as secure. It's typically one or two VPS's, and there is no signature or verification that the content is "official". So even if I'm not tampering with the binary, I can still tamper with the bash script to add extra goodies to it.

    On the other hand (but not really relevant to what OP is talking about), just because I trust someone to give me a binary in a mature programming language they have experience writing in, doesn't mean I trust them to give me a script in a language known for footguns. A steam bug in their bash script once deleted a user's home directory. There have also been issues with AUR packages, which are basically bash scripts, breaking people's systems as well. When it comes to user/community created scripts, I mostly trust them to not be malicious, and I am more fearful of a bug or mistake screwing things up. But at the same time, I have little confidence in my ability to spot these bugs.

    Generally, I only make an exception for running bash installers if the program being installed is a "platform" that I can use to install more software. K3s (Kubernetes distro), or the Nix package manager are examples. If I can install something via Nix or Docker then it's going to be installed via there and not installed via curl | bash. Not every developer under the sun should be given the privilege of running a bash script on my system.

    As a sidenote, docker doesn't recommend their install script anymore. All the instructions have been removed from the website, and they recommend adding their own repo's instead. Personally, I prefer to get it from the distro's repositories, as usually that's the simplest and fastest way to install docker nowadays.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 8 months ago

    Firstly, it is much, much easier to compromise the website hosting than the binary itself, usually. Distributed binaries are usually signed by multiple keys from multiple servers, resulting in them being highly resistant to tampering. Reproducible builds (two users compiling a program get the same output) make it trivial to detect tampering as well.

    Yeah this is a fair call.

    But at the same time, I have little confidence in my ability to spot these bugs.

    This is the key thing for me. I am not likely to spot any issues even if they were there! I'd only be scanning for external connections or obviously malicious code, which I do when I don't have as much trust in the source.

    As a sidenote, docker doesn’t recommend their install script anymore.

    Yeah I used it as an example because there are very few times I ever remember piping to bash, but that's probably the most common one I have done in the past.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 8 months ago (1 child)

    the difference though is you can check a script. if it’s an open source project, you can also compile from source. but I get what you mean

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 4 points 8 months ago

    You can, but to me it seems weird to say it's crazy to pipe to bash when people happily run binaries. If anything, the convenience script is lower risk than the binary since people have probably checked it before you.

    I wouldn't pipe a random script to bash though, nothing where I wouldn't trust the people behind it.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 5 points 8 months ago

    It's really only about trusting the source. Your operating system surely has thousands of scripts that you've never read and never checked. And wouldn't have time to. And people don't complain about that.

    But it's really bad practice to run random things from random sites. So the practice of downloading a script and running it is frowned upon. Mostly as a way of maintaining good security hygiene.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 8 months ago (1 child)
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 8 months ago

    That's an interesting proof of concept, but I don't think it shows it's different. That's a server side attack, whoever has control of the server could just have the script download a malicious binary instead and you wouldn't be able to tell from the script.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 17 points 8 months ago (1 child)

    Most developers I've looked at would happily just paste the curl|bash thing into the terminal.

    I often would skim the script in the browser, but a. This post shows that's not fool proof and b. a sufficiently sophisticated malicious script would fool a casual read

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 4 points 8 months ago

    Most developers I’ve looked at would happily just paste the curl|bash thing into the terminal.

    I mean, I typically see it used for installing applications, and so long as TLS is used for the download, I'm still not aware of a good reason why you should check the Bash script in particular in that case, since the application itself could just as well be malware.

    Of course, it's better to check the Bash script than to not check it, but at that point we should also advise to download the source code for the application, review it and then compile it yourself.
    At some point, you just have to bite the bullet and I have not yet seen a good argument why the Bash script deserves special treatment here...

    Having said that, for cases where you're not installing an application, yeah, reviewing the script allows you to use it, without having to trust the source to the same degree as you do for installing an application.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 16 points 8 months ago (3 children)

    The post is specifically about how you can serve a totally different script than the one you inspect. If you use curl to fetch the script via terminal, the webserver can send a different script to a browser based on the UserAgent.

    And whether or not you think someone would be mad to do it, it's still a widespread practice. The article mentions that piping curl straight to bash is already standard procedure for Proxmox helper scripts. But don't take anyone's word for it, check it out:

    https://community-scripts.github.io/ProxmoxVE/

    It's also the recommended method for PiHole:

    https://docs.pi-hole.net/main/basic-install/

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 7 points 8 months ago (2 children)

    The reality is a lot of newcomers to Linux won't even understand the risks involved, it's run because that's what they're told or shown to do. That's what I did for pihole many years ago too, I'll admit

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 8 months ago

    Users are blameless, I find the fault with the developers.

    Asking users to pipe curl to bash because it's easier for the developer is just the developer being lazy, IMO.

    Developers wouldn't get a free pass for taking lazy, insecure shortcuts in programming, I don't know why they should get a free pass on this.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 8 points 8 months ago* (1 child)

    In addition to the other examples it's also in the default installation mode for node.js - they use this to install nvm

    Ya cant even blame someone non-technical falling for this if they haven't been explicitly informed - it's getting reinforced as completely normal by too many "reputable" projects.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 0 points 8 months ago* (last edited 8 months ago) (1 child)

    I mean, true, but most of the things I do that with are private scripts that I wrote. I think the main exception to that is Oh-my-zsh.

    Also it's not really a full pipe...

    bash <(curl cht.sh/curl)

    That's saves the URL as a temporary file and opens it with bash. Frankly, the URL I gave you is very bad because it is not actually a script, just the help page for curl. Frankly, it would better if it wasn't nested.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •