5 ms·

Don't pipe curl/wget a script to a shell without reading what you've downloaded. This should be common sense. Do `wget $url; most install.sh` and only if you're

Don't pipe curl/wget a script to a shell without reading what you've downloaded. This should be common sense. Do `wget $url; most install.sh` and only if you're satisfied with what you read, execute `sh install.sh`.

cassianoleal 2y ago
As opposed to downloading a binary install file?
- yau8edq12i 2y ago
  Distributors usually give you a way to verify that what you've downloaded is correct, usually through checksums, PGP signatures, code signing... You forego that if you pipe the script to your shell. What if you make a typo and somehow pipe an HTML document to your shell? If you're unlucky this could wreak havoc.
  - cassianoleal 2y ago
    From the threat vectors you presented, I assume you already trust the vendor. That means you trust their installation script. You are, after all, going to run their binary after the installation! In this case, I assume the reason to inspect the script is not so much that the script might be doing something bad, but rather that you may have downloaded the wrong file to begin with. With that in mind: > Distributors usually give you a way to verify that what you've downloaded is correct The first thing is that not all software is downloaded from Linux distribution repositories. This technique doesn't work if you're just downloading an installer from a website or Github releases page, etc. Sure, many also provide you with a checksum that you need to manually verify, but the shell script in question can also do the same. In fact, it can help by automating the check after it inevitably downloads the application's binary package. In this case, the vector is you getting something different from what the vendor intended you to download. An example would be if your connection had been MITM'ed and a malicious package had been sent in its place. This is largely a non-issue these days with TLS certs everywhere, SNI, OCSP stapling and other protections that more or less ensure you're connected to the right server. > What if you make a typo and somehow pipe an HTML document to your shell? That's quite the bad luck! In this case, the user made a typo. Most `curl | bash` commands are copy-pasted from a website rather than typed out, so this is _mostly_ a non-issue as well. For those cases where the user typed the command and got it wrong, for it to become a problem, at least these 2 things need to be true: * the typoed URL actually downloaded something that the shell can interpret * there are commands in this downloaded document that actually wreak havoc to the system where they ran I fail to see a scenario where that would happen. Not that it's impossible, but it's so unrealistic that if it happened to me I might just shutdown the computer and go buy a lottery ticket!
- benlivengood 2y ago
  Having a distribution maintainer provide official packages is the best way.
  - zer00eyz 2y ago
    Thats who pushed XZ out as far as it went. Everyone is asleep at the wheel.
    - jakogut 2y ago
      Distribution maintainers are also the people that pushed out a fix as quickly as the compromised version was released. It's unrealistic to expect software to never have security holes, bugs, or vulnerabilities. How they're handled matters more than the fact that they were introduced to begin with.
    - arp242 2y ago
      A single incident. How many incidents in how many decades have there been?
      - zer00eyz 2y ago
        Ask the bottles team how they feel about maintainers and the job they are doing. A fair number of upstream developers are unhappy with what maintainers and how they deal with bugs and updates. The real problem is that software packaging and distribution is so very broken. I had a systems admin say "I love containers, they are a circle of salt around demonically bad software"... He wasnt wrong.
    - Hamuko 2y ago
      I thought that the xz backdoor was only in bleeding edge distributions?
bombcar 2y ago
Everyone says this, but nearly nobody does it. Just like security through open source, it's more a nice myth than a reality.
- bee_rider 2y ago
  I skim little python or bash scripts when I download them. It depends on the project. (I try not to download much source code because this is a pain to do).
- deleted 2y ago
  [deleted]
- ykonstant 2y ago
  I do it; I like messing with install scripts and optimize them. My next big yak shaving project will be to optimize rkhunter. Did you know it is a 20K line POSIX shell script? I read through it a couple of times, and there's significant potential for improvement both in performance and in its security. For me it's a lot of fun because I like programming in Bourne-derived shells.
constantcrying 2y ago
It is an awful habit of some open source projects to have the official way to install their software be to execute a shell script from the Internet. Nobody reads it, as they are usually quite complex and given the xz situation a well crafted shell script can seem harmless while being very dangerous.
- Hamuko 2y ago
  Didn't the xz situation kinda prove that even reading the script is probably not gonna do you a lot of good if you're up against someone smart?
  - xandrius 2y ago
    Exactly, also if you already go thinking in adversarial terms when using something, why would you even use the thing to begin with? Maybe I'm too naïve.
  - samtheprogram 2y ago
    > given the xz situation a well crafted shell script can seem harmless while being very dangerous That’s exactly what they are saying.
  - wizzwizz4 2y ago
    The xz situation proved the opposite: if you're up against someone smart, you won't read the script (and you'll think you have).
    - ta1243 2y ago
      The xz situation proved that while you didn't read the script, someone did detect the problem. It shows the benefit of many-eyes.
      - deleted 2y ago
        [deleted]
- 2y ago
idle_zealot 2y ago
While I agree, how does this mesh with standard operating procedure on Windows/Mac being to download binary executables and run them? Is the analogous advice "inspect any exe files with Ghidra and fully understand them before running"? Or "only run executables from official distribution channels of open source projects the code of which you've read and understand"? Where, generally, should we place our trust in terms of what code we run on our computers?
- OskarS 2y ago
  Windows and particularly macOS makes it difficult to run things that aren't code signed with trusted certificates. Same with packages in Linux package managers. That provides a large level of assurance that the thing you download is verified by a distributor that you presumably trust (otherwise why are you using their software?). Pipe to shell has no such guarantee: if a bad actor either MITMs you or gets access to their server and stuffs something bad in the script, you're out of luck. Basically, if you believe that code signing is a good thing (and I hope we all can agree on that), curl to shell is not great security practice.
IncreasePosts 2y ago
She'll is complicated enough that I suspect it would be quite easy to trick anyone who does a cursory glance over the script, unless they are an absolute shell master.
elzbardico 2y ago
Well, you're going to run the thing the script downloaded with exactly the same user and privileges as the script you're running. Unless you're doing a full audit on all the code and not only a cursory look on the installation script, this looks to me more like security theatre.
- yau8edq12i 2y ago
  Because if looking at the script you've downloaded for obvious errors or issues is not 100% effective, then it's only theater. Is that what you're saying?
busterarm 2y ago
My obligatory yearly scream into the void that the preferred way to install Rust is still `curl https://sh.rustup.rs https://sh.rustup.rs | sh` But security!
elzbardico 2y ago
A far better advice would be to: Unless you're read to fully analyze all the code and look for problems in the whole code, instead of just the install script, don't be an eager early adopter of every project you see posted somewhere, wait for it to have some social validation, give it sometime so smarter people with more time than us had their time looking for vulnerabilities in the whole code, not only on the script. Or if you really want to check it, use an isolated VM first.
mirekrusin 2y ago
curl -fsSL https://ollama.com/install.sh | sh && ollama run llama3 "Why it is bad to curl | sh?" ...for details.

cassianoleal 2y ago

As opposed to downloading a binary install file?

yau8edq12i 2y ago
Distributors usually give you a way to verify that what you've downloaded is correct, usually through checksums, PGP signatures, code signing... You forego that if you pipe the script to your shell. What if you make a typo and somehow pipe an HTML document to your shell? If you're unlucky this could wreak havoc.
- cassianoleal 2y ago
  From the threat vectors you presented, I assume you already trust the vendor. That means you trust their installation script. You are, after all, going to run their binary after the installation! In this case, I assume the reason to inspect the script is not so much that the script might be doing something bad, but rather that you may have downloaded the wrong file to begin with. With that in mind: > Distributors usually give you a way to verify that what you've downloaded is correct The first thing is that not all software is downloaded from Linux distribution repositories. This technique doesn't work if you're just downloading an installer from a website or Github releases page, etc. Sure, many also provide you with a checksum that you need to manually verify, but the shell script in question can also do the same. In fact, it can help by automating the check after it inevitably downloads the application's binary package. In this case, the vector is you getting something different from what the vendor intended you to download. An example would be if your connection had been MITM'ed and a malicious package had been sent in its place. This is largely a non-issue these days with TLS certs everywhere, SNI, OCSP stapling and other protections that more or less ensure you're connected to the right server. > What if you make a typo and somehow pipe an HTML document to your shell? That's quite the bad luck! In this case, the user made a typo. Most `curl | bash` commands are copy-pasted from a website rather than typed out, so this is _mostly_ a non-issue as well. For those cases where the user typed the command and got it wrong, for it to become a problem, at least these 2 things need to be true: * the typoed URL actually downloaded something that the shell can interpret * there are commands in this downloaded document that actually wreak havoc to the system where they ran I fail to see a scenario where that would happen. Not that it's impossible, but it's so unrealistic that if it happened to me I might just shutdown the computer and go buy a lottery ticket!
benlivengood 2y ago
Having a distribution maintainer provide official packages is the best way.
- zer00eyz 2y ago
  Thats who pushed XZ out as far as it went. Everyone is asleep at the wheel.
  - jakogut 2y ago
    Distribution maintainers are also the people that pushed out a fix as quickly as the compromised version was released. It's unrealistic to expect software to never have security holes, bugs, or vulnerabilities. How they're handled matters more than the fact that they were introduced to begin with.
  - arp242 2y ago
    A single incident. How many incidents in how many decades have there been?
    - zer00eyz 2y ago
      Ask the bottles team how they feel about maintainers and the job they are doing. A fair number of upstream developers are unhappy with what maintainers and how they deal with bugs and updates. The real problem is that software packaging and distribution is so very broken. I had a systems admin say "I love containers, they are a circle of salt around demonically bad software"... He wasnt wrong.
  - Hamuko 2y ago
    I thought that the xz backdoor was only in bleeding edge distributions?

bombcar 2y ago

Everyone says this, but nearly nobody does it. Just like security through open source, it's more a nice myth than a reality.

bee_rider 2y ago
I skim little python or bash scripts when I download them. It depends on the project. (I try not to download much source code because this is a pain to do).
deleted 2y ago
[deleted]
ykonstant 2y ago
I do it; I like messing with install scripts and optimize them. My next big yak shaving project will be to optimize rkhunter. Did you know it is a 20K line POSIX shell script? I read through it a couple of times, and there's significant potential for improvement both in performance and in its security. For me it's a lot of fun because I like programming in Bourne-derived shells.

constantcrying 2y ago

It is an awful habit of some open source projects to have the official way to install their software be to execute a shell script from the Internet. Nobody reads it, as they are usually quite complex and given the xz situation a well crafted shell script can seem harmless while being very dangerous.

Hamuko 2y ago
Didn't the xz situation kinda prove that even reading the script is probably not gonna do you a lot of good if you're up against someone smart?
- xandrius 2y ago
  Exactly, also if you already go thinking in adversarial terms when using something, why would you even use the thing to begin with? Maybe I'm too naïve.
- samtheprogram 2y ago
  > given the xz situation a well crafted shell script can seem harmless while being very dangerous That’s exactly what they are saying.
- wizzwizz4 2y ago
  The xz situation proved the opposite: if you're up against someone smart, you won't read the script (and you'll think you have).
  - ta1243 2y ago
    The xz situation proved that while you didn't read the script, someone did detect the problem. It shows the benefit of many-eyes.
    - deleted 2y ago
      [deleted]
2y ago

idle_zealot 2y ago

While I agree, how does this mesh with standard operating procedure on Windows/Mac being to download binary executables and run them? Is the analogous advice "inspect any exe files with Ghidra and fully understand them before running"? Or "only run executables from official distribution channels of open source projects the code of which you've read and understand"? Where, generally, should we place our trust in terms of what code we run on our computers?

OskarS 2y ago
Windows and particularly macOS makes it difficult to run things that aren't code signed with trusted certificates. Same with packages in Linux package managers. That provides a large level of assurance that the thing you download is verified by a distributor that you presumably trust (otherwise why are you using their software?). Pipe to shell has no such guarantee: if a bad actor either MITMs you or gets access to their server and stuffs something bad in the script, you're out of luck. Basically, if you believe that code signing is a good thing (and I hope we all can agree on that), curl to shell is not great security practice.

IncreasePosts 2y ago

She'll is complicated enough that I suspect it would be quite easy to trick anyone who does a cursory glance over the script, unless they are an absolute shell master.

elzbardico 2y ago

Well, you're going to run the thing the script downloaded with exactly the same user and privileges as the script you're running. Unless you're doing a full audit on all the code and not only a cursory look on the installation script, this looks to me more like security theatre.

yau8edq12i 2y ago
Because if looking at the script you've downloaded for obvious errors or issues is not 100% effective, then it's only theater. Is that what you're saying?

busterarm 2y ago

My obligatory yearly scream into the void that the preferred way to install Rust is still `curl https://sh.rustup.rs https://sh.rustup.rs | sh` But security!

elzbardico 2y ago

A far better advice would be to: Unless you're read to fully analyze all the code and look for problems in the whole code, instead of just the install script, don't be an eager early adopter of every project you see posted somewhere, wait for it to have some social validation, give it sometime so smarter people with more time than us had their time looking for vulnerabilities in the whole code, not only on the script. Or if you really want to check it, use an isolated VM first.

mirekrusin 2y ago

curl -fsSL https://ollama.com/install.sh | sh && ollama run llama3 "Why it is bad to curl | sh?" ...for details.