There is debate on whether this is really a security concern.
[0] https://www.arp242.net/curl-to-sh.html [1] https://sandstorm.io/news/2015-09-24-is-curl-bash-insecure-p...
[0] https://www.arp242.net/curl-to-sh.html [1] https://sandstorm.io/news/2015-09-24-is-curl-bash-insecure-p...
About your second observation, please keep it quiet. We have more than enough with the flat-earthers. We do not need another cult.
One side is a small-but-vocal minority making silly arguments. "how to detect direct piping to bash in order to serve malware"? An attacker who tries to serve different things to different people will easily be caught, and a simple diff will highlight their exploit. A much more robust attack strategy is to serve the same malware to everyone but obfuscate it. Make the vulnerability look like an innocent bug, and you have plausible deniability. This same attack works for every approach to software distribution, it's not unique to curl|bash.
The vast majority of pragmatic people just don't think there's an issue here, don't find these arguments convincing, and don't care to argue about it. I run the Sandstorm project, which uses curl|bash, and this issue really hasn't impacted adoption. Our users aren't naive, they understand what curl|bash is, but they also recognize that obviously by installing our software they are giving us arbitrary code execution. Users who don't trust us install Sandstorm in a separate VM -- the only reasonable way to run software you are suspicious of.
The very intelligent people at Docker used to have this pattern at get.docker.io. They changed it.
And to obfuscate the attack, I think typo squatting in package managers like npm and pip, might be a blue print.
If anything, I think package managers create a false sense of security, especially ones that allow anyone to publish packages and declare dependencies on anything else. Installing an npm package -- even one from someone you trust -- could very easily transitively install something malicious. Debian packages are arguably better in that not just anyone can push packages to Debian's main package repo, but there's still a very real danger of a hidden backdoor. But I think a lot of people just assume installing from a package manager is not dangerous.
> The very intelligent people at Docker used to have this pattern at get.docker.io. They changed it.
Probably not for security reasons, though. There's a separate, very legitimate argument for distro packages, which is that they implicitly promise to play nicely with your distro's conventions and install themselves in a clean, manageable way. How to update or uninstall a distro package is well-defined. None of this is actually guaranteed, of course -- a package can do whatever it wants in an install hook. But assuming you trust the developer isn't malicious, then you can get some comfort knowing the package is unlikely to screw up your system.
curl|bash provides no such promise, even implicitly. Who the hell knows what it might decide to do. Maybe it has one of those `rm -rf $SOME_VAR_THAT_MIGHT_NOT_BE_DEFINED/*` bugs like Steam did at one point.
Sandstorm is careful to avoid messing up anything, installing itself to a self-contained directory, and providing an uninstall script. But the user doesn't really know that in advance.
The reason to use curl|bash in spite of this is because distro packaging is a lot of work (there are a lot of distros!) and may not be the best use of time for a small project. Docker is definitely big enough to do it, though.
So yeah, there's definitely a cleanliness argument. But the security argument is bogus.
It's still downloading and executing a script, just two steps instead of piping the output straight into bash.
You can't even inspect the code you run when you do curl|bash and the server is able to detect this distinction and hide code when you do a curl and then run bash.
https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
Your argument is: "we do it and we use GitHub, you can trust us and can trust GitHub, you don't need to verify the code you run."
And devs learn: "Trust me, you don't need to verify the code you run."
You got me. The last time I installed Docker, I remember doing it using packages, so I assumed that was the replacement. Looking at their comment, it looks like they got tired of people arguing about it, so they changed the instructions to sidestep the argument. I don't think they seriously believe this made a security difference.
> You can't even inspect the code you run when you do curl|bash and the server is able to detect this distinction and hide code when you do a curl and then run bash.
I addressed exactly this argument two comments ago.
> Your argument is: "we do it and we use GitHub, you can trust us and can trust GitHub, you don't need to verify the code you run."
When did I ever say anything about GitHub? This isn't my argument at all.
> And devs learn: "Trust me, you don't need to verify the code you run."
Come on, nobody actually verifies all the code they run.
Can be detected, and will be detected are quite different. I don't know of any scanning projects even attempting to detect such things.
Creating a subtle, plausibly-accidental bug and then exploiting it is much safer.
Comparisons with flat earthers is just insulting.
Github is technically like a bazaar or mall. It's wrong to assume that if you trust a store on the bazaar you then trust ALL stores on the bazaar. You personally may, but then I strongly question your sense of security. Sure, you trust that Github doesn't add malicious stuff when cloning, but each repo on Github is kinda it's own "server" to fit into your analogy.
FWIW though, if Github servers have a vuln that allows attackers to modify repo content being served on a per-request basis, it's pretty likely that many repos (or even all repos) would be vulnerable, not just one. From a security standpoint I'd consider Github repo servers to be a tier of servers that you do or don't trust; saying that you trust one "server" within the tier but don't trust another doesn't make a lot of sense, especially since you don't actually know the topology behind their DNS and the "servers" are virtualized, colocated, and parts of them are ephemeral. What exactly are you trusting? Other than "I sent a request to Github and it gave me a response" there's not much you can say for certain — the request could've been routed to any number of repo servers, that may be hosting dozens of other repos on them as well. The server that responds today is likely a different virtualized server than the one that responds tomorrow, just attached to the same filesystem. But even if that weren't true, curl-to-bash in this example seems ultimately fine for most people.
If I were doing devops work that required Kubescape for an org, I would definitely package it into a deb (or whatever package format the org used internally) and install it that way rather than curl-to-bash. But that's not because of security gains from a deb vs a script, that's because I'd want to lock it to a stable version rather than always installing latest, and I wouldn't want to tie availability of Kubescape to Github repo servers being up (they do go down sometimes). But for getting started playing around with it, curl-to-bash is low friction, can easily support multiple OSes as compared to debs, and seems generally fine as it is used here.
No doubt, these conventions can be and are ignored, but they are good conventions.
If it's okay on GH, we train the user to think it's okay on less secure sites.
Most people who eschew curl|bash as being a fine thing rely quite heavily on the notion that TLS is infallible.
But there's a lot more dangerous to it than that; half-downloaded scripts or scripts which check your useragent and change content depending on the method of download.
It's just a stupid foot gun, best to avoid aiming guns at feet.