4 ms·

> the good old "curl <some url> | bash" I would be thankful if the habit of trusting a random IP with control of one's shell could die, forever.

by Iv 9y ago

0xFFFE 9y ago
Precisely. Why would anyone do that is beyond me.
jjnoakes 9y ago
Why would you be using a random ip? That incantation is usually used with a URL where you would have just downloaded and installed the software manually anyway. There are various arguments against the curl-piped-to-shell idiom but "random ip" doesn't seem like a valid one.
- shakna 9y ago
  A URL and an IP are not equal. Building a script that acts differently for a web browser, a normal download, and curl, is trivial, and I've seen it happen. Here's a proof-of-concept[0] someone else wrote. Manually downloading is safer, at least you can review, curling straight into a shell is inherently unsafe. The better option is still a package manager, but curling straight to a shell is very unsafe. [0] https://jordaneldredge.com/blog/one-way-curl-pipe-sh-install-scripts-can-be-dangerous/ https://jordaneldredge.com/blog/one-way-curl-pipe-sh-install...
  - jjnoakes 9y ago
    Why would you be using an IP and not a URL? And why wouldn't you trust the source of the install script as much as any other installer? Do you audit the binary installers you use as well? I don't disagree about a minor difference between the methods, but I definitely disagree with piping to sh being "very unsafe". If you trust the site/author enough to run their code on your computer at all, the install method risk difference is but a tiny drop in the bucket.
    - shakna 9y ago
      > If you trust the site/author enough to run their code on your computer at all Piping curl, means you can't be sure it came from the author's site. It means you can't be sure you're getting the same software you've been considering installing. It means a broken connection is a broken install, with no cleanup and no idea what it has changed. > Do you audit the binary installers you use as well? Don't install random binaries either. The security implications of that should be fairly obvious.
      - Spivak 9y ago
        > Piping curl, means you can't be sure it came from the author's site. Up to the trustworthiness of the CA system yes you can. If the author's site is serving malicious downloads to the curl UA then you're probably hosed either way. It would be easier to just slip malicious code in the software itself. > It means a broken connection is a broken install, with no cleanup and no idea what it has changed. This is the real draw of package management. The argument surrounding curl|bash should really focus on this rather than hand-wavy security. > Don't install random binaries either Nobody who is running curl|bash isn't installing a 'random' binary but downloading an installer from a source they trust.
        shakna 9y ago
        > Up to the trustworthiness of the CA system yes you can. If the author's site is serving malicious downloads to the curl UA then you're probably hosed either way. It would be easier to just slip malicious code in the software itself. If they have HSTS, otherwise you might end up using plain ol' http by accident. Like over at surge.sh, but at least they use a package manager. > Nobody who is running curl|bash isn't installing a 'random' binary but downloading an installer from a source they trust. But you can't trust it, because most shell scripts out there are woefully inadequate. So you're one broken connection, one WiFi drop, from corrupting your system. At least a binary needs to be complete to run. Example: Heroku's CLI [0] If it breaks on the echo, you could end up overwriting your entire source list. e.g. It breaks to: echo "deb https://cli-assets.heroku.com/branches/stable/apt https://cli-assets.heroku.com/branches/stable/apt ./" > /etc/apt/sources.list instead of the intended echo "deb https://cli-assets.heroku.com/branches/stable/apt https://cli-assets.heroku.com/branches/stable/apt ./" > /etc/apt/sources.list.d/heroku.list And it'll work too, because the entire thing runs as the root user. > The argument surrounding curl|bash should really focus on this rather than hand-wavy security. They're the same thing. A broken connection with curl | sh is a security problem. As is downgraded https, because of an accidentally misconfigured host. As is running without even the basic check of seeing if you get the complete file before executing it. Everything about curl | sh is inherently untrustworthy. [0] https://cli-assets.heroku.com/install-ubuntu.sh https://cli-assets.heroku.com/install-ubuntu.sh

> the good old "curl <some url> | bash" I would be thankful if the habit of trusting a random IP with control of one's shell could die, forever.

by Iv 9y ago

> the good old "curl <some url> | bash" I would be thankful if the habit of trusting a random IP with control of one's shell could die, forever.

0xFFFE 9y ago

Precisely. Why would anyone do that is beyond me.

jjnoakes 9y ago

Why would you be using a random ip? That incantation is usually used with a URL where you would have just downloaded and installed the software manually anyway. There are various arguments against the curl-piped-to-shell idiom but "random ip" doesn't seem like a valid one.

shakna 9y ago
A URL and an IP are not equal. Building a script that acts differently for a web browser, a normal download, and curl, is trivial, and I've seen it happen. Here's a proof-of-concept[0] someone else wrote. Manually downloading is safer, at least you can review, curling straight into a shell is inherently unsafe. The better option is still a package manager, but curling straight to a shell is very unsafe. [0] https://jordaneldredge.com/blog/one-way-curl-pipe-sh-install-scripts-can-be-dangerous/ https://jordaneldredge.com/blog/one-way-curl-pipe-sh-install...
- jjnoakes 9y ago
  Why would you be using an IP and not a URL? And why wouldn't you trust the source of the install script as much as any other installer? Do you audit the binary installers you use as well? I don't disagree about a minor difference between the methods, but I definitely disagree with piping to sh being "very unsafe". If you trust the site/author enough to run their code on your computer at all, the install method risk difference is but a tiny drop in the bucket.
  - shakna 9y ago
    > If you trust the site/author enough to run their code on your computer at all Piping curl, means you can't be sure it came from the author's site. It means you can't be sure you're getting the same software you've been considering installing. It means a broken connection is a broken install, with no cleanup and no idea what it has changed. > Do you audit the binary installers you use as well? Don't install random binaries either. The security implications of that should be fairly obvious.
    - Spivak 9y ago
      > Piping curl, means you can't be sure it came from the author's site. Up to the trustworthiness of the CA system yes you can. If the author's site is serving malicious downloads to the curl UA then you're probably hosed either way. It would be easier to just slip malicious code in the software itself. > It means a broken connection is a broken install, with no cleanup and no idea what it has changed. This is the real draw of package management. The argument surrounding curl|bash should really focus on this rather than hand-wavy security. > Don't install random binaries either Nobody who is running curl|bash isn't installing a 'random' binary but downloading an installer from a source they trust.
      - shakna 9y ago
        > Up to the trustworthiness of the CA system yes you can. If the author's site is serving malicious downloads to the curl UA then you're probably hosed either way. It would be easier to just slip malicious code in the software itself. If they have HSTS, otherwise you might end up using plain ol' http by accident. Like over at surge.sh, but at least they use a package manager. > Nobody who is running curl|bash isn't installing a 'random' binary but downloading an installer from a source they trust. But you can't trust it, because most shell scripts out there are woefully inadequate. So you're one broken connection, one WiFi drop, from corrupting your system. At least a binary needs to be complete to run. Example: Heroku's CLI [0] If it breaks on the echo, you could end up overwriting your entire source list. e.g. It breaks to: echo "deb https://cli-assets.heroku.com/branches/stable/apt https://cli-assets.heroku.com/branches/stable/apt ./" > /etc/apt/sources.list instead of the intended echo "deb https://cli-assets.heroku.com/branches/stable/apt https://cli-assets.heroku.com/branches/stable/apt ./" > /etc/apt/sources.list.d/heroku.list And it'll work too, because the entire thing runs as the root user. > The argument surrounding curl|bash should really focus on this rather than hand-wavy security. They're the same thing. A broken connection with curl | sh is a security problem. As is downgraded https, because of an accidentally misconfigured host. As is running without even the basic check of seeing if you get the complete file before executing it. Everything about curl | sh is inherently untrustworthy. [0] https://cli-assets.heroku.com/install-ubuntu.sh https://cli-assets.heroku.com/install-ubuntu.sh