5 ms·

What is wrong with curl | sh with HTTPS? Linux does essentially the same thing with GPG signatures instead.

ceejayoz 10y ago
I'm fairly comfortable with `curl | sh` over HTTPS, but to my knowledge, the servers serving the GPG signatures for Linux packages aren't able to sign them with the right keys.
- CiPHPerCoder 10y ago
  GPG is great for offline signatures, which in addition to HTTPS is a great way to assure that the software you obtain is legitimate. That isn't to say that it isn't the product of a targeted trojan signed with a stolen GPG key.
jakub_g 10y ago
There was a nice writeup some time ago that the server can detect piping to shell via some properties of that call, and perhaps send an exploit in such case: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b... https://news.ycombinator.com/item?id=11532599 https://news.ycombinator.com/item?id=11532599
- burke 10y ago
  Ok, here's the thing: Almost no one actually audits the source they download before they run it, whether it be a package installer, a configure/make/make-install tarball, or a curl|sh. If you know enough to audit a shellscript, you can easily decompose the command-line to download, audit, and run the local copy. For the vast majority that chooses to simply trust the author, there is no additional security issue with curl|sh compared to other non-signed distribution methods provided the script is wrapped in a function call or otherwise resistant to errors that might happen if a partial download is executed. Should we do better than curl|sh? Yes. But it's no worse than downloading some random tarball or even cloning some random git repository, as long as it's served over HTTPS.
  - antocv 10y ago
    >Almost no one actually audits the source they download before they run it, Thats not the security issue here, its effectively running build-time logic during install-time, on every bodies machine at every install, instead of at package maintainers secure build system, once, and having the installation basically be an unpack instruction. Another negative point of curl | bash, is you assume your users are idiots who do not know their OS package manager well enough to run apt-get install shitpackage pacman -S shitpackage or apk add shitpackage.
    - burke 10y ago
      > Another negative point of curl | bash, is you assume your users are idiots who do not know their OS package manager well enough to run apt-get install shitpackage pacman -S shitpackage or apk add shitpackage. Absolutely, but packaging for all major distributions can be a larger headache than writing the project in the first place. For a lot of small projects, this isn't justifiable.
  - vhost- 10y ago
    Another issue is partially written responses. If the connection fails in the middle of your curl (or the source's application crashes) you can receive part of a shell script that could very well contain `rm -rf /usr`. Edit: I cooked up an example actually. Here is a small Go program that will panic after 1 nanosecond: https://gist.github.com/kyleterry/dc304503dfca2d149b189694d13617b8 https://gist.github.com/kyleterry/dc304503dfca2d149b189694d1... This will sometimes return partial responses. Run this in a bash `while true` loop and curl localhost:8080 a few times. You will mostly see empty and full responses because my example isn't perfect, but occasionally you will only get part of the script dumped to the screen and that's the problem with curl|bash.
    - mark-wagner 10y ago
      The "curl | bash" usages I've seen from reputable sources avoid that by defining a single bash function f and then executing the the function as the final character, i.e.: function f { echo "hello world" } f
antocv 10y ago
It doesnt ever work. Ive yet to see a "curl https://thisshit.net/trust/us/really/we/have/https https://thisshit.net/trust/us/really/we/have/https | bash" script which didnt fail for whatever dumb reason, such as only working on specific variants of Ubuntu, with specific packages installed in specific version, and/or RedHat. Usually these shit scripts fail when trying them out, for curiosity, in ArchLinux, Gentoo or Alpine Linux. Sandstorm.io looking at you. If you are already going to invest in making "an install script" with defined/researched which packages/versions with which your software needs, for various platforms - submit this data to that platform as an debian/{control,etc} to make a .deb or specfile for .rpm or PKGBUILD or whatever, and use the platforms _build tools_ to generate a platform specific package - be a package mantainer if you have to. Another side effect of telling your users to curl | bash, is I wont ever use your software. You didnt make the effort to do the right thing with packaging, why would you have done any better for whatever it is youre trying to do with your shit software? (sandstorm again).
- geofft 10y ago
  Don't all the same criticisms apply to `./configure && make install`?
  - antocv 10y ago
    Sure, so make it clear what curl | bash is, tell your users "we dont have any packages for your system, here is the source and we use X build tool, please do ./configure && make install, or cmake or whatever", that would have been nice. When I have to install packages from source, I have a more secure/locked down linux container, with seccomp applied, dropped capabilities etc, then if I intend to use the the software over longer time, and expect updates, I skim the source and build-system quality, quickly write a PKGBUILD or APKBUILD, build it, install it into its own new container - with iptables filtering outgoing connections, and thats it, sometimes submit the APKBUILD to alpine testing or aur. And all this is easier than curl | bash oh watch it fail for dumb reason in the install script - and I did try that, the time spent troubleshooting the install script is longer than time to sandbox the whole thing as described above. So, if I can do it, why cant the project? Why spend their efforts on writing an install script instead of package-build instructions to various distributions?
z869900 10y ago
If you download a tarball, you can google the sha256sum to see if at least Debian, a couple of mailing lists etc. have the same one. If your GPG signature is in your keychain, it's safer anyway. HTTPS by itself does not protect against malicious content or malicious actors (DigiNotar, TurkTrust, GCHQ, ...)
balls187 10y ago
> What is wrong with curl | sh with HTTPS? That you may unwittingly opening up your machine to vulnerabilities. Most sophisticated people won't execute remote scripts from untrusted sources, but as more people switch to unix-like operating systems, they may have as much scrutiny. A designer on my team was given a mac, and if a script failed to run locally, he would immediately re-run the script using `sudo.` I can't imagine he was the only person to use this solution.

I'm fairly comfortable with `curl | sh` over HTTPS, but to my knowledge, the servers serving the GPG signatures for Linux packages aren't able to sign them with the right keys.

CiPHPerCoder 10y ago
GPG is great for offline signatures, which in addition to HTTPS is a great way to assure that the software you obtain is legitimate. That isn't to say that it isn't the product of a targeted trojan signed with a stolen GPG key.

jakub_g 10y ago

There was a nice writeup some time ago that the server can detect piping to shell via some properties of that call, and perhaps send an exploit in such case: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b... https://news.ycombinator.com/item?id=11532599 https://news.ycombinator.com/item?id=11532599

burke 10y ago
Ok, here's the thing: Almost no one actually audits the source they download before they run it, whether it be a package installer, a configure/make/make-install tarball, or a curl|sh. If you know enough to audit a shellscript, you can easily decompose the command-line to download, audit, and run the local copy. For the vast majority that chooses to simply trust the author, there is no additional security issue with curl|sh compared to other non-signed distribution methods provided the script is wrapped in a function call or otherwise resistant to errors that might happen if a partial download is executed. Should we do better than curl|sh? Yes. But it's no worse than downloading some random tarball or even cloning some random git repository, as long as it's served over HTTPS.
- antocv 10y ago
  >Almost no one actually audits the source they download before they run it, Thats not the security issue here, its effectively running build-time logic during install-time, on every bodies machine at every install, instead of at package maintainers secure build system, once, and having the installation basically be an unpack instruction. Another negative point of curl | bash, is you assume your users are idiots who do not know their OS package manager well enough to run apt-get install shitpackage pacman -S shitpackage or apk add shitpackage.
  - burke 10y ago
    > Another negative point of curl | bash, is you assume your users are idiots who do not know their OS package manager well enough to run apt-get install shitpackage pacman -S shitpackage or apk add shitpackage. Absolutely, but packaging for all major distributions can be a larger headache than writing the project in the first place. For a lot of small projects, this isn't justifiable.
- vhost- 10y ago
  Another issue is partially written responses. If the connection fails in the middle of your curl (or the source's application crashes) you can receive part of a shell script that could very well contain `rm -rf /usr`. Edit: I cooked up an example actually. Here is a small Go program that will panic after 1 nanosecond: https://gist.github.com/kyleterry/dc304503dfca2d149b189694d13617b8 https://gist.github.com/kyleterry/dc304503dfca2d149b189694d1... This will sometimes return partial responses. Run this in a bash `while true` loop and curl localhost:8080 a few times. You will mostly see empty and full responses because my example isn't perfect, but occasionally you will only get part of the script dumped to the screen and that's the problem with curl|bash.
  - mark-wagner 10y ago
    The "curl | bash" usages I've seen from reputable sources avoid that by defining a single bash function f and then executing the the function as the final character, i.e.: function f { echo "hello world" } f

antocv 10y ago

It doesnt ever work. Ive yet to see a "curl https://thisshit.net/trust/us/really/we/have/https https://thisshit.net/trust/us/really/we/have/https | bash" script which didnt fail for whatever dumb reason, such as only working on specific variants of Ubuntu, with specific packages installed in specific version, and/or RedHat. Usually these shit scripts fail when trying them out, for curiosity, in ArchLinux, Gentoo or Alpine Linux. Sandstorm.io looking at you. If you are already going to invest in making "an install script" with defined/researched which packages/versions with which your software needs, for various platforms - submit this data to that platform as an debian/{control,etc} to make a .deb or specfile for .rpm or PKGBUILD or whatever, and use the platforms _build tools_ to generate a platform specific package - be a package mantainer if you have to. Another side effect of telling your users to curl | bash, is I wont ever use your software. You didnt make the effort to do the right thing with packaging, why would you have done any better for whatever it is youre trying to do with your shit software? (sandstorm again).

geofft 10y ago
Don't all the same criticisms apply to `./configure && make install`?
- antocv 10y ago
  Sure, so make it clear what curl | bash is, tell your users "we dont have any packages for your system, here is the source and we use X build tool, please do ./configure && make install, or cmake or whatever", that would have been nice. When I have to install packages from source, I have a more secure/locked down linux container, with seccomp applied, dropped capabilities etc, then if I intend to use the the software over longer time, and expect updates, I skim the source and build-system quality, quickly write a PKGBUILD or APKBUILD, build it, install it into its own new container - with iptables filtering outgoing connections, and thats it, sometimes submit the APKBUILD to alpine testing or aur. And all this is easier than curl | bash oh watch it fail for dumb reason in the install script - and I did try that, the time spent troubleshooting the install script is longer than time to sandbox the whole thing as described above. So, if I can do it, why cant the project? Why spend their efforts on writing an install script instead of package-build instructions to various distributions?

z869900 10y ago

If you download a tarball, you can google the sha256sum to see if at least Debian, a couple of mailing lists etc. have the same one. If your GPG signature is in your keychain, it's safer anyway. HTTPS by itself does not protect against malicious content or malicious actors (DigiNotar, TurkTrust, GCHQ, ...)

balls187 10y ago

> What is wrong with curl | sh with HTTPS? That you may unwittingly opening up your machine to vulnerabilities. Most sophisticated people won't execute remote scripts from untrusted sources, but as more people switch to unix-like operating systems, they may have as much scrutiny. A designer on my team was given a mac, and if a script failed to run locally, he would immediately re-run the script using `sudo.` I can't imagine he was the only person to use this solution.