51–60 of 104 posts
Earlier quoted context omitted.
The linked repo isn't from the NSA, it's from armosec. Who, afaict, don't have zero days in their possession.
Sorry misread ... You are right. Still, I will not execute a shell script from a github repository to find security issues ...
Earlier quoted context omitted.
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...
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.
I politely suggest that a security focused tool should not further the curl|bash pattern.
Earlier quoted context omitted.
The linked repo isn't from the NSA, it's from armosec. Who, afaict, don't have zero days in their possession.
Sorry misread ... You are right. Still, I will not execute a shell script from a github repository to find security issues ...
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 mode”, and rightly so.
(This is in answer to the below question from another user. I’m too lazy to do two threaded responses on mobile. Maybe if mobile wasn’t such a shit platform with tiny ass screens and software keyboards that didn’t duck up everything you typed-ahh help there it goes again I swear to god Steve when I die I’m coming down there to kick your ass you son of a…)
I politely suggest that a security focused tool should not further the curl|bash pattern.
What alternative pattern would you suggest?
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?)
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…
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.
Earlier quoted context omitted.
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…
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 fro…
There's CIS KubeBench and OpenSCAP as other comments mentioned. I don't trust an organization that keeps Zero days to themselves for offensive capabilities.
Earlier quoted context omitted.
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 fro…
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…
This is not like some kind of "normal" software distribution pattern. Every other modern OS in the world has solved the trust issues by either verifying the software is signed, or requiring you click some button that says "I acknowledge that I am about to totally fuck up my PC with this untrusted software". The Linux distros verify package signatures, Windows verifies exe signatures, Macs do too (afaik?), Android and iOS do.
Curling to a pipe is just devs being lazy. The trust issues were solved a while ago. Not that devs being lazy is anything new. Literally the only reason anyone can use Linux at all without spending 2 weeks setting it up by hand is because somebody other than the software developers did the hard work of packaging it correctly. The curl|bash pattern is just the `./configure && make && make install` of modern devs. (But even then you could still verify the tarball signature before untarring it)