6 ms·

What alternative pattern would you suggest?

by geofft 5y ago

anotherhue 5y ago
binary packages, maybe through github releases. debian packages, potentially upstreamed into the package repos (though that's some effort). It's quite presumptive to presume to know how a target system is to be configured. no matter which alternative, curl|bash is security risk enough to never use: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b... gpg can help (below from zerotier): curl -s 'https://raw.githubusercontent.com/zerotier/ZeroTierOne/master/doc/contact%40zerotier.com.gpg https://raw.githubusercontent.com/zerotier/ZeroTierOne/maste...' | gpg --import && \ if z=$(curl -s 'https://install.zerotier.com/ https://install.zerotier.com/' | gpg); then echo "$z" | sudo bash; fi
- geofft 5y ago
  What's the advantage of binary packages through GitHub releases? How do you audit them? I'm aware of the fact that you can detect curl | bash server-side, and it's a neat trick, but I don't understand the security risk of it. The server is supplying you with arbitrary content that you're not auditing - what does it matter if it supplies you different arbitrary content? What's the advantage of the GPG approach? Last I checked, the GPG command was capable of signing malicious binaries. I do agree about the configuration argument. But that's not a security argument.
  - anotherhue 5y ago
    I think you may be conflating the application owner and the delivery system. If we're installing the application I think we're implicitly trusting the author. If you copy/paste http instead of https then you've given execution control to every single middlebox along the way. If the code is hosted on an evil sourceforge, then you've given them execution control. deb packages will do signature checks, any many authors will list checksums in their releases which we can use to verify.
    - shawnz 5y ago
      All these arguments apply no matter the packaging format. Install scripts can be signed and checksummed too. Only by having your package put into a repository already trusted by the user in advance do you solve these problems, it's not an issue with the packaging format being a shell script versus a deb package.
      - kortilla 5y ago
        I don’t think you understand how signed packages work. They give you the ability to be sure you are installing software packaged by an entity you trust, regardless of where you get the package.
        shawnz 5y ago
        I understand. That only moves the problem to where you get the signature from, it doesn't solve it (unless you are using a central repo you already trust for example). Therefore binary packages shipped on a GitHub releases page alongside a signature file still face the same issue. An attacker simply has to replace both the package and the signature with one they control. It is nothing to do with the packaging format being a deb file instead of an install script, the issue applies in either case.
        throwaway984393 5y ago
        Public key servers. Upload your key to 3 different key servers (keyserver.pgp.com, keyserver.ubuntu.com, pgp.mit.edu). Have the user download it from all 3, verify they're the same, verify the package signature with the public key. People already do essentially this (but from one key server) when they add custom PPAs to a distro. In order to hack that package, someone would have to either A) steal the signing key from the developer's airgapped laptop, or B) hack github.com and 3 independent key servers.
        shawnz 5y ago
        The point is not whether it's a solvable problem. The point is that it's not conventional to go to such extents, no matter what kind of packaging you use. This kind of process could be done with either install scripts or deb/rpm packages with nearly the same level of effort, but nobody conventionally does this kind of thing with either (maybe with the exception of stuff that's in a central repo, where you do get SOME protection by default). So it's wrong to say that install scripts are the cause of the problem. The common pattern of "curl | sh" is just as bad as the common pattern of "download a deb and install it". It's not an improvement to simply shun install scripts without solving the actual trust issue.
- Zababa 5y ago
  In all of these cases you also outsource the security to someone that you trust. How is that different from curl https... | sh ? Who says that no one took over the github, or the debian package?
- nonameiguess 5y ago
  They actually have binary releases created through github: https://github.com/armosec/kubescape/releases/tag/v1.0.64 https://github.com/armosec/kubescape/releases/tag/v1.0.64 The only thing the installer script is doing is autodetecting your OS, picking the correct binary release, downloading it, making it executable, and copying it to /usr/local/bin. The installation instructions could just as easily tell you to do that. As with most go programs, the entire thing is just one file. No libraries, no config files, no dependencies. Heck, wrapping it in a deb, rpm, and tarball for pacman would be easy as heck, just a one-line installer script: install -m755 <program> <prefix>/bin. I guess single-application developers just really don't like package managers.
- goodpoint 5y ago
  A binary download is almost worse. Edit: and why even more silent downvotes?
throwaway888abc 5y ago
Appimage or Docker container
throwaway984393 5y ago
Every Linux distribution for the past 20+ years has been using public key signatures to verify software before installing it. This has the benefit of a system already having a trusted key to verify against, so packaging with a Linux distro not only makes installation simpler and more reliable (mirrors for redundancy), it also makes verification simpler. However, it is also trivial to do independent verification. 1) Generate a GPG private key. 2) Upload the public key to a public key server. 3) Sign your software with the key and generate a .asc file. 4) Upload your .asc file along with the software you signed to your hoster of choice. 5) Have the user copy+paste a shell one-liner that will download the files, download the public key from the public key server, import the key, verify the files are signed correctly, and install them. The end result is cryptographic verification of your software before installation (using a 3rd party, or possibly multiple 3rd parties if you use multiple key servers) and the user only had to copy+paste a one-liner. It's not as cool as piping to bash, but it's more secure, and more reliable (what happens when your download fails half way through installing through this bash pipe? what happens if bash hangs half way through? what if you want to install offline?)
raesene9 5y ago
Using cosign/sigstore to sign release artifacts https://github.com/sigstore/cosign https://github.com/sigstore/cosign and instructions for validating signature on download could be a good option here.

What alternative pattern would you suggest?

by geofft 5y ago

What alternative pattern would you suggest?

binary packages, maybe through github releases. debian packages, potentially upstreamed into the package repos (though that's some effort). It's quite presumptive to presume to know how a target system is to be configured. no matter which alternative, curl|bash is security risk enough to never use: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b... gpg can help (below from zerotier): curl -s 'https://raw.githubusercontent.com/zerotier/ZeroTierOne/master/doc/contact%40zerotier.com.gpg https://raw.githubusercontent.com/zerotier/ZeroTierOne/maste...' | gpg --import && \ if z=$(curl -s 'https://install.zerotier.com/ https://install.zerotier.com/' | gpg); then echo "$z" | sudo bash; fi

geofft 5y ago
What's the advantage of binary packages through GitHub releases? How do you audit them? I'm aware of the fact that you can detect curl | bash server-side, and it's a neat trick, but I don't understand the security risk of it. The server is supplying you with arbitrary content that you're not auditing - what does it matter if it supplies you different arbitrary content? What's the advantage of the GPG approach? Last I checked, the GPG command was capable of signing malicious binaries. I do agree about the configuration argument. But that's not a security argument.
- anotherhue 5y ago
  I think you may be conflating the application owner and the delivery system. If we're installing the application I think we're implicitly trusting the author. If you copy/paste http instead of https then you've given execution control to every single middlebox along the way. If the code is hosted on an evil sourceforge, then you've given them execution control. deb packages will do signature checks, any many authors will list checksums in their releases which we can use to verify.
  - shawnz 5y ago
    All these arguments apply no matter the packaging format. Install scripts can be signed and checksummed too. Only by having your package put into a repository already trusted by the user in advance do you solve these problems, it's not an issue with the packaging format being a shell script versus a deb package.
    - kortilla 5y ago
      I don’t think you understand how signed packages work. They give you the ability to be sure you are installing software packaged by an entity you trust, regardless of where you get the package.
      - shawnz 5y ago
        I understand. That only moves the problem to where you get the signature from, it doesn't solve it (unless you are using a central repo you already trust for example). Therefore binary packages shipped on a GitHub releases page alongside a signature file still face the same issue. An attacker simply has to replace both the package and the signature with one they control. It is nothing to do with the packaging format being a deb file instead of an install script, the issue applies in either case.
        throwaway984393 5y ago
        Public key servers. Upload your key to 3 different key servers (keyserver.pgp.com, keyserver.ubuntu.com, pgp.mit.edu). Have the user download it from all 3, verify they're the same, verify the package signature with the public key. People already do essentially this (but from one key server) when they add custom PPAs to a distro. In order to hack that package, someone would have to either A) steal the signing key from the developer's airgapped laptop, or B) hack github.com and 3 independent key servers.
        shawnz 5y ago
        The point is not whether it's a solvable problem. The point is that it's not conventional to go to such extents, no matter what kind of packaging you use. This kind of process could be done with either install scripts or deb/rpm packages with nearly the same level of effort, but nobody conventionally does this kind of thing with either (maybe with the exception of stuff that's in a central repo, where you do get SOME protection by default). So it's wrong to say that install scripts are the cause of the problem. The common pattern of "curl | sh" is just as bad as the common pattern of "download a deb and install it". It's not an improvement to simply shun install scripts without solving the actual trust issue.
Zababa 5y ago
In all of these cases you also outsource the security to someone that you trust. How is that different from curl https... | sh ? Who says that no one took over the github, or the debian package?
nonameiguess 5y ago
They actually have binary releases created through github: https://github.com/armosec/kubescape/releases/tag/v1.0.64 https://github.com/armosec/kubescape/releases/tag/v1.0.64 The only thing the installer script is doing is autodetecting your OS, picking the correct binary release, downloading it, making it executable, and copying it to /usr/local/bin. The installation instructions could just as easily tell you to do that. As with most go programs, the entire thing is just one file. No libraries, no config files, no dependencies. Heck, wrapping it in a deb, rpm, and tarball for pacman would be easy as heck, just a one-line installer script: install -m755 <program> <prefix>/bin. I guess single-application developers just really don't like package managers.
goodpoint 5y ago
A binary download is almost worse. Edit: and why even more silent downvotes?

throwaway888abc 5y ago

Appimage or Docker container

throwaway984393 5y ago

Every Linux distribution for the past 20+ years has been using public key signatures to verify software before installing it. This has the benefit of a system already having a trusted key to verify against, so packaging with a Linux distro not only makes installation simpler and more reliable (mirrors for redundancy), it also makes verification simpler. However, it is also trivial to do independent verification. 1) Generate a GPG private key. 2) Upload the public key to a public key server. 3) Sign your software with the key and generate a .asc file. 4) Upload your .asc file along with the software you signed to your hoster of choice. 5) Have the user copy+paste a shell one-liner that will download the files, download the public key from the public key server, import the key, verify the files are signed correctly, and install them. The end result is cryptographic verification of your software before installation (using a 3rd party, or possibly multiple 3rd parties if you use multiple key servers) and the user only had to copy+paste a one-liner. It's not as cool as piping to bash, but it's more secure, and more reliable (what happens when your download fails half way through installing through this bash pipe? what happens if bash hangs half way through? what if you want to install offline?)

raesene9 5y ago

Using cosign/sigstore to sign release artifacts https://github.com/sigstore/cosign https://github.com/sigstore/cosign and instructions for validating signature on download could be a good option here.