The installation instructions (curl -s get.gvmtool.net | bash) as well as download location in the installation script (GVM_SERVICE="http://api.gvmtool.net") are plain HTTP and therefore subject to exploit and vulnerability injection. Given this tool also provides other development tools, this provides a wide surface for attacks.
Please change the installation routine to use TLS for the initial script download and within the script as well for downloading the appropriate binaries. If cost is a concern, CloudFlare provides free SSL - https://www.cloudflare.com/ssl.
I'd also like to add that the installation instructions should not recommend piping a URL directly to bash. Instead, it should be performed in two discrete steps.
curl -s get.gvmtool.net -o gvm-setup.sh && bash gvm-setup.sh
(or whatever it needs to be to considered correct)
The reasons curl should not be piped directly to the shell are outlined clearly in the following post:
http://blog.existentialize.com/dont-pipe-to-your-shell.html
The main point is that by piping, you aren't even waiting for the connection to terminate properly before you decide to execute the script.
”Friends don't let friends pipe to shell.”
+1
+1
What I also wouldn't mind to see is this tool become self contained, and not have to source 10+ scripts in my main bash environement.
@mojavelinux I have read that wrapping a bash script in braces will prevent it from being executed when not fully downloaded: https://news.ycombinator.com/item?id=9754637
+1, this is insecure lacking https support -- a MITM / DNS attack results in malicious shell commands running on the host.
Why is this still open after more than year?
+1 for https. Would like to use sdkman in Docker builds for jitpack.io but can't do plain http.
I have some experience with cloudflare ssl user so would be happy to help out if needed.
+1 for https. You can get a free TLS certificate from Let's Encrypt. You may think your project is too insignificant for someone to write an injection attack against it, but the install method would fall prey to a generic bash script injection attack.
It' coming soon. I'm busy migrating all services over to Digital Ocean, which will allow us to run our own nginx, hence we will have SSL enabled on all endpoints.
Okay, good news is that we are now all SSL'ed up. I'll be updating the bash client soon to start consuming https too. For now you can get started by installing over SSL.
What about changing the instructions to not pipe directly to bash?
Pull requests welcome.
Most helpful comment
It' coming soon. I'm busy migrating all services over to Digital Ocean, which will allow us to run our own nginx, hence we will have SSL enabled on all endpoints.