7 ms·

Please do not pipe scripts downloaded through curl into bash. Use a package manager. That way the downloaded binary can be verified against a checksum and/or GP

Please do not pipe scripts downloaded through curl into bash. Use a package manager. That way the downloaded binary can be verified against a checksum and/or GPG signing.

da39a3ee 4y ago
Please don't contribute worthless and irrelevant comments like this. As you doubtless well know, piping from curl into bash is something that a large subset of respected programmers think is reasonable, and another rather tedious subset do not. For example, the entire Rust community clearly has a consensus that it's reasonable: https://rustup.rs/ https://rustup.rs/ As does homebrew https://brew.sh/ https://brew.sh/ and pyenv https://github.com/pyenv/pyenv-installer#install https://github.com/pyenv/pyenv-installer#install to name whatever came to my mind in 30s thought. Since the debate has such large numbers on both sides, your individual opinion on it is neither interesting nor germane.
- aspaceman 4y ago
  "a bunch of folks do something insecure" does not speak argument. The argument is that it is insecure. Most easily because I can inject, "cat ~/.ssh/*_rsa | curl ..." and get your company ssh keys. There's no reason rust, brew and all the rest can't provide a Download page with a checksum. They choose not to, like this project chose not to, because it doesn't look as sexy. It's really silly.
  - yunohn 4y ago
    Why can’t the downloaded binary package do the exact same thing? Or do you decompile and go through those as well?
    - aspaceman 4y ago
      It could, but I can trust that no individual stepped in the middle of that process. I trust Rust to not put such a thing in their binary. I do not trust an arbitrary man in the middle, and it's trivial to modify a shell script. Without a checksum, I can't ensure the binary im piping through the shell is the binary they posted and built. Anyone can step in, modify a few lines, and get access to a large part of my system. The barrier to entry to add such capability to arbitrary binaries is outrageously high.
      - yunohn 4y ago
        Install scripts are usually hosted on GitHub/etc and changes are clearly tracked. Compiled binaries are untracked and do not offer the same guarantees. I would trust the script more than a binary that could’ve been modified anywhere along the build process. Not everyone uses Linux, and not every package can be audited by repo devs. It’s simply not scalable.
  - qbasic_forever 4y ago
    If someone has pulled off a sophisticated enough attack to intercept your http curl of the script and inject a malicious version, why can't they also intercept your brower http requests for the download page and inject different html that gives a good hash/checksum of the malicious script? Going even further, what is stopping a malicious attack on the package source itself--like someone gaining control of the package source and committing a malicious version (as NPM, pypi and other registries have seen)? The point is, "use your package manager" is not any better in the grand scheme of things than blindly curling and executing a script. Neither option is perfectly secure.
    - nine_k 4y ago
      No, the concern is not your computer is compromised. Yours is a low-value target, sorry. It's their http server, or a machine that feeds that http server, which is a good target for a compromise. Injecting a little bit of malicious code that steals something, or installs a fileless piece of malware, would bring massive benefits to the perpetrator, even if the exploit is short-lived. That shell script should be a zip (gzip, xz) file, with a sha256 hash of it published on a different, separately hosted resource. Maybe we should provide an utility that just does that in one command. It could even be a shell script...
      - qbasic_forever 4y ago
        Realistically a poisoned ARP or DNS attack that redirects your machine's traffic to the attacker's server, both for the download and the download page, is something to be concerned about. This only requires someone to have access to your local network, not to your machine. It could be as innocent as working at a coffee shop from their wifi network and an attacker being on it too...
        moondev 4y ago
        curl validates the TLS certificate by default, it will fail in your scenario unless you pass -k. dev TLD requires https on all connections
  - moondev 4y ago
    > Most easily because I can inject, "cat ~/.ssh/*_rsa | curl ..." If you can inject that breaking TLS which secures everything on the internet, why can't you inject your own checksum on the "download page"?
    - zbird 4y ago
      Checksums and the binaries can be stored in different places for redundancy.
  - lillecarl 4y ago
    Sure you can, but there's always going to be trust somewhere. I trust that the curl | bash examples I see are from reputable sources, and I trust their infra as much as someone else's to be safe (https protects MITM attacks). NixOS is a cool example of complete package transparency with their binary cache, if your expressions don't evaluate the same as theirs you'll build from source. But really, curl | bash isn't the end of the world. If they do it against a github url they also have the security of github behind you, because you can't differentiate on user agent there, which seems to be the commonly argued pitfall. Or other ways to detect you're not a browser, on a hosted platform you have someone else's security team behind your back.
- inetsee 4y ago
  Have you read the Hacker News Guidelines, particularly the section labeled "In Comments"? If you haven't, I suggest that you should.
  - yunohn 4y ago
    Do you mean for the original comment complaining about the script? > Please don't complain about tangential annoyances—things like article or website formats, name collisions, or back-button breakage. They're too common to be interesting. > Avoid unrelated controversies, generic tangents, and internet tropes. > Please don't post shallow dismissals, especially of other people's work. > Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead.
- LanternLight83 4y ago
  I for one think that this individual opinion has value under this post as a PSA to people who might not otherwise give the command a second thought, regardless of the conclusion they take away.
- OJFord 4y ago
  Why do you think your opinion is more valuable than that to which you reply? For what it's worth, I can rattle off many more project names at random in 30s, and odds are they'll all have installation methods that aren't curl-pipe-shell, there are just so many more of them.
  - da39a3ee 4y ago
    Please read what I wrote more carefully: I wasn't giving an opinion (other than the word "tedious"). I was pointing out the fact that there are large numbers of experienced software engineers on both sides of this argument, and hence it isn't an argument that can be settled, or even helpfully contributed to, by individuals giving their opinions. It's got to the point where it's more like politics or religion or something.
- zbird 4y ago
  Trusting it because other people trust it for no apparent reason does not seem like a very compelling argument. For all I know, the Rust and homebrew communities know squat about how to securely deliver binaries.
- user00012-ab 4y ago
  I wish I could upvote da39a3ee's comment 100 more times. I hate condescending know it all people, and da39a3ee stated this way more eloquently then I would have.
yunohn 4y ago
The developer has accounted for this with a prominent link to the file in question, see “View the script that will be executed here”.
- tslocum 4y ago
  This actually doesn't protect you the way you think it does. Using a simple check of the user agent which makes the request, an innocuous file may be served to browser requests, while an infected file may be served to cURL requests.
  - kej 4y ago
    You can even get more devious and use timing differences to serve one thing to `curl` and a different thing to `curl | bash`: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
samatman 4y ago
Definitely don't curl | less first if you're concerned, or make a tmpfile if you're really paranoid. That would be using your tools, not kvetching online. And we can't have that.
ReganLaitila 4y ago
Please lend your own time and energy to generate packages for bespoke distributions and package managers. You will need: deb, rpm, apk, AppImage, casks, tars, and likely more. Make sure to spend your time submitting your package to maintainers for each repository/registry for each distribution and each distro version. Don't forget to test each and every permutation! Is all that too hard? No problem. Stand up your own repository for each distribution mechanism and instruct the user to run a bunch of random curl and key handling commands to bind their machine to this new software supply chain attack channel. At least this 'potentially malicious' code is being checksumed/gpg verified! -- the point -- 'curl | sh' is inherently no different from a trust perspective then issuing a package installation command or installing a new repository source for a package manager. Each user makes the value judgement if they trust the software or not. Your free to run the 'curl' part and inspect the script, or contribute packages to the byzantine linux/unix ecosystem if it boils your blood so hard. Practicality is a feature sometimes.
- 411111111111111 4y ago
  It is inherently different, because it's been proven that you can detect the use of curl|bash Serverside. This makes it possible to serve the malicious payload only to people which do that. But I'd agree that the hurdle to get your package into system repositories likely ain't with it. People are free to compile it themselves, download it manually or whatever floats their boats if they don't want to use the quick and easy install script... Which they can audit by saving it to the filesystem before executing the file.
  - ReganLaitila 4y ago
    "It is inherently different, because it's been proven that you can detect the use of curl|bash Serverside" Malicious people do malicious things? I worry that we conflate trust with validity. Some package systems do it better than others, but in principle you trust that for example, a maintainer of a package repository is not serving you bad checksums and malicious content. After all these systems get their checksums/keys on-first-use, so you still need to make the trust judgement. And they could still change the responses based on your ip, user agent, or other metadata they have access to when you interact with the system. To boil it down to my gripe, the comments about checksums/gpg signing being the reason to never 'curl | sh' make no sense until you can clear the trust argument first, which no one does. And once you do clear the trust argument, and conclude the source is trustworthy, we can have a more technical debate on the distribution mechanism itself and what makes sense from that perspective. edit: forgot to add, 'curl | sh' is also a trust on-first-use scenario just like with package ecosystems.

Please do not pipe scripts downloaded through curl into bash. Use a package manager. That way the downloaded binary can be verified against a checksum and/or GPG signing.

da39a3ee 4y ago

Please don't contribute worthless and irrelevant comments like this. As you doubtless well know, piping from curl into bash is something that a large subset of respected programmers think is reasonable, and another rather tedious subset do not. For example, the entire Rust community clearly has a consensus that it's reasonable: https://rustup.rs/ https://rustup.rs/ As does homebrew https://brew.sh/ https://brew.sh/ and pyenv https://github.com/pyenv/pyenv-installer#install https://github.com/pyenv/pyenv-installer#install to name whatever came to my mind in 30s thought. Since the debate has such large numbers on both sides, your individual opinion on it is neither interesting nor germane.

aspaceman 4y ago
"a bunch of folks do something insecure" does not speak argument. The argument is that it is insecure. Most easily because I can inject, "cat ~/.ssh/*_rsa | curl ..." and get your company ssh keys. There's no reason rust, brew and all the rest can't provide a Download page with a checksum. They choose not to, like this project chose not to, because it doesn't look as sexy. It's really silly.
- yunohn 4y ago
  Why can’t the downloaded binary package do the exact same thing? Or do you decompile and go through those as well?
  - aspaceman 4y ago
    It could, but I can trust that no individual stepped in the middle of that process. I trust Rust to not put such a thing in their binary. I do not trust an arbitrary man in the middle, and it's trivial to modify a shell script. Without a checksum, I can't ensure the binary im piping through the shell is the binary they posted and built. Anyone can step in, modify a few lines, and get access to a large part of my system. The barrier to entry to add such capability to arbitrary binaries is outrageously high.
    - yunohn 4y ago
      Install scripts are usually hosted on GitHub/etc and changes are clearly tracked. Compiled binaries are untracked and do not offer the same guarantees. I would trust the script more than a binary that could’ve been modified anywhere along the build process. Not everyone uses Linux, and not every package can be audited by repo devs. It’s simply not scalable.
- qbasic_forever 4y ago
  If someone has pulled off a sophisticated enough attack to intercept your http curl of the script and inject a malicious version, why can't they also intercept your brower http requests for the download page and inject different html that gives a good hash/checksum of the malicious script? Going even further, what is stopping a malicious attack on the package source itself--like someone gaining control of the package source and committing a malicious version (as NPM, pypi and other registries have seen)? The point is, "use your package manager" is not any better in the grand scheme of things than blindly curling and executing a script. Neither option is perfectly secure.
  - nine_k 4y ago
    No, the concern is not your computer is compromised. Yours is a low-value target, sorry. It's their http server, or a machine that feeds that http server, which is a good target for a compromise. Injecting a little bit of malicious code that steals something, or installs a fileless piece of malware, would bring massive benefits to the perpetrator, even if the exploit is short-lived. That shell script should be a zip (gzip, xz) file, with a sha256 hash of it published on a different, separately hosted resource. Maybe we should provide an utility that just does that in one command. It could even be a shell script...
    - qbasic_forever 4y ago
      Realistically a poisoned ARP or DNS attack that redirects your machine's traffic to the attacker's server, both for the download and the download page, is something to be concerned about. This only requires someone to have access to your local network, not to your machine. It could be as innocent as working at a coffee shop from their wifi network and an attacker being on it too...
      - moondev 4y ago
        curl validates the TLS certificate by default, it will fail in your scenario unless you pass -k. dev TLD requires https on all connections
- moondev 4y ago
  > Most easily because I can inject, "cat ~/.ssh/*_rsa | curl ..." If you can inject that breaking TLS which secures everything on the internet, why can't you inject your own checksum on the "download page"?
  - zbird 4y ago
    Checksums and the binaries can be stored in different places for redundancy.
- lillecarl 4y ago
  Sure you can, but there's always going to be trust somewhere. I trust that the curl | bash examples I see are from reputable sources, and I trust their infra as much as someone else's to be safe (https protects MITM attacks). NixOS is a cool example of complete package transparency with their binary cache, if your expressions don't evaluate the same as theirs you'll build from source. But really, curl | bash isn't the end of the world. If they do it against a github url they also have the security of github behind you, because you can't differentiate on user agent there, which seems to be the commonly argued pitfall. Or other ways to detect you're not a browser, on a hosted platform you have someone else's security team behind your back.
inetsee 4y ago
Have you read the Hacker News Guidelines, particularly the section labeled "In Comments"? If you haven't, I suggest that you should.
- yunohn 4y ago
  Do you mean for the original comment complaining about the script? > Please don't complain about tangential annoyances—things like article or website formats, name collisions, or back-button breakage. They're too common to be interesting. > Avoid unrelated controversies, generic tangents, and internet tropes. > Please don't post shallow dismissals, especially of other people's work. > Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead.
LanternLight83 4y ago
I for one think that this individual opinion has value under this post as a PSA to people who might not otherwise give the command a second thought, regardless of the conclusion they take away.
OJFord 4y ago
Why do you think your opinion is more valuable than that to which you reply? For what it's worth, I can rattle off many more project names at random in 30s, and odds are they'll all have installation methods that aren't curl-pipe-shell, there are just so many more of them.
- da39a3ee 4y ago
  Please read what I wrote more carefully: I wasn't giving an opinion (other than the word "tedious"). I was pointing out the fact that there are large numbers of experienced software engineers on both sides of this argument, and hence it isn't an argument that can be settled, or even helpfully contributed to, by individuals giving their opinions. It's got to the point where it's more like politics or religion or something.
zbird 4y ago
Trusting it because other people trust it for no apparent reason does not seem like a very compelling argument. For all I know, the Rust and homebrew communities know squat about how to securely deliver binaries.
user00012-ab 4y ago
I wish I could upvote da39a3ee's comment 100 more times. I hate condescending know it all people, and da39a3ee stated this way more eloquently then I would have.

yunohn 4y ago

The developer has accounted for this with a prominent link to the file in question, see “View the script that will be executed here”.

tslocum 4y ago
This actually doesn't protect you the way you think it does. Using a simple check of the user agent which makes the request, an innocuous file may be served to browser requests, while an infected file may be served to cURL requests.
- kej 4y ago
  You can even get more devious and use timing differences to serve one thing to `curl` and a different thing to `curl | bash`: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

samatman 4y ago

Definitely don't curl | less first if you're concerned, or make a tmpfile if you're really paranoid. That would be using your tools, not kvetching online. And we can't have that.

ReganLaitila 4y ago

Please lend your own time and energy to generate packages for bespoke distributions and package managers. You will need: deb, rpm, apk, AppImage, casks, tars, and likely more. Make sure to spend your time submitting your package to maintainers for each repository/registry for each distribution and each distro version. Don't forget to test each and every permutation! Is all that too hard? No problem. Stand up your own repository for each distribution mechanism and instruct the user to run a bunch of random curl and key handling commands to bind their machine to this new software supply chain attack channel. At least this 'potentially malicious' code is being checksumed/gpg verified! -- the point -- 'curl | sh' is inherently no different from a trust perspective then issuing a package installation command or installing a new repository source for a package manager. Each user makes the value judgement if they trust the software or not. Your free to run the 'curl' part and inspect the script, or contribute packages to the byzantine linux/unix ecosystem if it boils your blood so hard. Practicality is a feature sometimes.

411111111111111 4y ago
It is inherently different, because it's been proven that you can detect the use of curl|bash Serverside. This makes it possible to serve the malicious payload only to people which do that. But I'd agree that the hurdle to get your package into system repositories likely ain't with it. People are free to compile it themselves, download it manually or whatever floats their boats if they don't want to use the quick and easy install script... Which they can audit by saving it to the filesystem before executing the file.
- ReganLaitila 4y ago
  "It is inherently different, because it's been proven that you can detect the use of curl|bash Serverside" Malicious people do malicious things? I worry that we conflate trust with validity. Some package systems do it better than others, but in principle you trust that for example, a maintainer of a package repository is not serving you bad checksums and malicious content. After all these systems get their checksums/keys on-first-use, so you still need to make the trust judgement. And they could still change the responses based on your ip, user agent, or other metadata they have access to when you interact with the system. To boil it down to my gripe, the comments about checksums/gpg signing being the reason to never 'curl | sh' make no sense until you can clear the trust argument first, which no one does. And once you do clear the trust argument, and conclude the source is trustworthy, we can have a more technical debate on the distribution mechanism itself and what makes sense from that perspective. edit: forgot to add, 'curl | sh' is also a trust on-first-use scenario just like with package ecosystems.