cURLing and Piping To Bash

cURLing and Piping To Bash

…But Torres is ready. She initiates the power surge she has set up. On the bridge, Seven of Nine suddenly stands ramrod-straight, a vacant, paralysed expression on its face. The look is replaced by one of sheer agony as it cries out in excruciating pain. It raises a hand to the back of its head as an implant located there sparks with a bright light, overloaded and destroyed by Torres’ power surge. It finally sinks down and slumps over the helm console, unconscious.

Man in the Middle attack

OK, so that example isn’t exactly the same as curling to bash, but the end result is what this post is about: what will that computer code do when you run it? You might think you are running or installing one thing, but something completely different happens.

Why Is There So Much Controversy Surrounding This Issue?

Computer code can be written to do anything: encrypt your files and hold them ransom, steal your passwords, or even physically destroy equipment at a nuclear complex.

Alternatively, computer code can also produce many useful things that allow us to communicate across great distances, create and share amazing content, or even watch TV shows anywhere we are.


So knowing that computer code can be programmed to do anything, does it come down to how much you trust the developer? Let’s take a look.

The Good

Many people use TextExpander, (a personal favorite of mine because it can do more than just expand text). But TextExpander is closed source, so you can’t really know what the app is doing, yet you might choose to install it anyway.

The software also needs your admin password to install and operate properly–something that malware tries to very hard to accomplish because once it has your password, it can do anything it wants.

Because the Smile Software and the TextExpander have a good reputation, you might be more inclined to blindly install it.

The Bad

Here’s another example: SourceForge. For the longest time, it was a great site to download and install free software. Many people lost trust in the site after they bundled malware with legitimate pieces of software. You can still find legitimate software on the site, but many people will look elsewhere first.

The Ugly

Man in the middle attacks can happen in ways you might not suspect. Take SuperFish, the malware that came pre-installed on brand new Lenovo computers. Customers trusted that a brand new computer should be virus-free, but it wasn’t.

Open Source vs. Closed Source

Commercial and/or proprietary software are often closed source so the developers have good reason to keep it malware-free: so they can stay profitable.

Alternatively, many open source projects are purely volunteer-operated (like us). It’s in their best interests to make a good product to earn the trust of their user base.

It only takes one developer to turn a legitimate app into a piece of malware. If that person is working on a closed source piece of software, you may never know it’s infected until it’s too late. It is more risky to try to inject malware into an open source project because it’s available for anyone to see. In addition, the code usually needs to be reviewed by others working on the project before being approved.

The Most Basic Programs Of All

If you know anything about UNIX-like operating systems, you know there exist some very basic programs–programs we might take for granted as a basic function of the operating system but are actually programs in and of themselves.

Let’s say you wanted to see what files exist in a directory. You’re going to use the ls command. Now this is a built-in command and anyone who has spent any decent amount of time at the command line will be familiar with it. But have you ever looked at the source code for ls?

What if an operating system included a rogue version of the ls command that was actually malware? Would you ever know the difference if it still listed your files? It’s unlikely to happen, but it seems to me like it would be a good attack vector because people use ls every single day.

If you wanted to run your malware all the time, why not embed it in a command that is so commonplace, no one would ever think to look there? Your malware could run silently every day with no one the wiser. So the next time you are cping, mving, cding, and sshing your way around the command line, take a moment to think about malware.

Installation Methods

I have discussed trust, open vs. closed source, and even some rudimentary programs. Knowing these things, we can discuss the installation methods. There are many different ways to install software (I list just a few):

  1. curling and piping to bash
  2. third party App store (i.e. Play Store, App Store)
  3. Drag-and-drop (i.e. .dmg)
  4. Direct installation (some sort of installer like a .pkg, InstallShield, etc.)
  5. Package manager (apt, yum, rpm, Homebrew, Macports, etc.)
  6. CD/DVD installation

The developer may choose one or the other depending on many things. So is one safer than the other? If you talk about digitally signed apps, then you would probably say yes, and I would tend to agree with you; it provides another layer of protection. However, these security measures have been bypassed before and it’s not unrealistic to think it can happen again.

Piping To Bash

Yes, it’s risky.

Yes, you could end up running something different than what you intend.

Yes, not everyone recommends it (but many people offer it as an installation method).

Should you do it?

Learn what you can about it and make your own decision based on the risks, benefits, and level of convenience that it will take to get the software installed.

2 Responses

  1. Lawrence says:

    Great page. I see a typo you might like to fix: in the phrase “This is much more risky try with open source software…” I’m pretty sure you meant “than” not “try”.

    Would be nice if somehow you could extend the discussion (and your software) to help people for whom all of this is a little over our heads… like a semi-geek on a Mac (sort of Unix I guess) like me.

  2. Wang says:

    > Yes, not everyone recommends it (but many people offer it as an installation method).

    Using the “Logical fallacy: appeal to common practice” isn’t a good reason to let some rando run code on your machine.

Comments are closed.