61–70 of 104 posts
Earlier quoted context omitted.
Sorry misread ... You are right. Still, I will not execute a shell script from a github repository to find security issues ...
why will you not if you can read the script?
do you know that you get the right binary blob?
If you use that to increase your security, ...
Earlier quoted context omitted.
There is a vast community who thinks it's bad, and unsafe (with examples on how to detect direct piping to bash in order to serve malware) and a few ones condoning it. That seems like saying there is currently a debate on the roundness of the planet Earth.
Ultimately, the only insecure thing about curl-to-bash is if you don't trust the server — the server in this case being Github. I think few people or companies include Github-being-malicious in their threat model; if Github was malicious, any build artifacts produced by even cloning from Github would be potentially suspect, since Github could fairly easily detect automated build agents and serve them different conten…
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.
Earlier quoted context omitted.
There is a vast community who thinks it's bad, and unsafe (with examples on how to detect direct piping to bash in order to serve malware) and a few ones condoning it. That seems like saying there is currently a debate on the roundness of the planet Earth.
Yes, it's exactly like that, but not in the way you think. 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.…
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.
Earlier quoted context omitted.
Ultimately, the only insecure thing about curl-to-bash is if you don't trust the server — the server in this case being Github. I think few people or companies include Github-being-malicious in their threat model; if Github was malicious, any build artifacts produced by even cloning from Github would be potentially suspect, since Github could fairly easily detect automated build agents and serve them different conten…
I'm not going to go into the curl|sh debate, but there is actually something wrong about what you described. Trusting the server doesn't apply to Github at all. 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…
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.
Earlier quoted context omitted.
Ultimately, the only insecure thing about curl-to-bash is if you don't trust the server — the server in this case being Github. I think few people or companies include Github-being-malicious in their threat model; if Github was malicious, any build artifacts produced by even cloning from Github would be potentially suspect, since Github could fairly easily detect automated build agents and serve them different conten…
I'm not going to go into the curl|sh debate, but there is actually something wrong about what you described. Trusting the server doesn't apply to Github at all. 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…
Earlier quoted context omitted.
Sorry misread ... You are right. Still, I will not execute a shell script from a github repository to find security issues ...
I actually came into the comments to make a joke about that very thing :-) Even if you read the file first, you have no guarantees that the file bash gets from curl, should you copy/paste the commands in the readme, is the same thing. Yeah it’s way outside what anyone would ever consider “reasonable” to be that paranoid, the mere mention of certain 3-letter agencies trigger any informed person’s built in “paranoid mo…
Of course for a properly, professionally paranoid person, you would download every component manually and store the received artifacts locally (for caching, reproducibility, TOFU principle and general BCP needs). Then build from those only. In fact, in high-trust environments it's common for CI systems to not be able to hit internet at all.
and Kubernetes also added StatefulSets for things like database, but all kubernetes gurus don't recommend to use it in Cloud, but use databases provided by the cloud providers :facepalm because, well, it's too complicated...
I politely suggest that a security focused tool should not further the curl|bash pattern.
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...
Earlier quoted context omitted.
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.
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…
You can literally pull it from a compromised machine with an active attacker and it doesn’t matter. It either has integrity and it’s safe or it fails to install.
That’s a huge difference from encouraging people to exec curl statements from random websites loading JavaScript from ad networks, trackers, etc, etc. You’re not only trusting the original dev, you’re now having to trust the web host and all of the other locations the page sources JavaScript from.
This is why any systems serious about security used signed packages. There are way too many systems/parties in between that can knowingly or unknowingly comprise https downloads. Windows updates, Linux updates (for the majority of package managers), iOS updates, Android updates, etc.
The trust model of “curl | sh” is severely worse than signed packages. They are in no way equivalent.