3 ms·

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-insta

by 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
  - vhost- 10y ago
    Totally, this is a good way to protect from that. It's just impossible to trust that is what someone is doing without going and looking at the script unfortunately.
glandium 10y ago
Note that neither dpkg -i nor rpm -i with a downloaded .deb or .rpm is any better than curl | sh. Installing .deb or .rpm packages is more than just unpacking an archive, it's effectively giving root to the package author: both .deb and .rpm files can have embedded scripts that are run at install time. This is probably true for all Linux distro package formats (I hope there are exceptions, but I'm not putting too much faith in that).

by burke 10y ago

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
- vhost- 10y ago
  Totally, this is a good way to protect from that. It's just impossible to trust that is what someone is doing without going and looking at the script unfortunately.

glandium 10y ago

Note that neither dpkg -i nor rpm -i with a downloaded .deb or .rpm is any better than curl | sh. Installing .deb or .rpm packages is more than just unpacking an archive, it's effectively giving root to the package author: both .deb and .rpm files can have embedded scripts that are run at install time. This is probably true for all Linux distro package formats (I hope there are exceptions, but I'm not putting too much faith in that).