Packages signing is meant to indicate that the downloaded package comes from the root source and hasn't been modified in transit. Thanks to this packages can be distributed by many carriers and without a need for transit security(means http) and you still can verify if it's legit and coming from the trusted source - which you ultimately trust just because you trusted their key in the first place. If for shell script you have only one carrier which is the root trusted origin, you're eliminating the need for packages signing. So can't see any added value between packages signing and shellscript in this particular scenario.
Threat model here is that we just trust atomic corp, as at the end of the day we're using URLs from that script to download and install actual repo keys. Cheers, Dawid Bałut <https://www.linkedin.com/in/dawidbalut> Founder of InfoSec Remedy <https://infosecremedy.blogspot.com/> Blogger at dawidbalut.blogspot.com 2017-04-10 22:35 GMT+02:00 Eero Volotinen <[email protected]>: > Well, rpm packages are signed with gpg and shellscripts are not. > > -- > Eero > > 2017-04-10 23:27 GMT+03:00 Dawid Bałut <[email protected]>: > >> Can you tell bit more why Eero? >> If the script and hosting is trusted, then it isn't deadly sin as long as >> it goes via https. >> There is no practical difference between wget https://example.com/abc.sh >> -O /tmp/abc.sh && sh /tmp/abc.sh and wget https://example.com/abc.sh |sh >> if you assume that the source and transit are safe and trusted. >> >> Cheers, >> Dawid Bałut <https://www.linkedin.com/in/dawidbalut> >> Founder of InfoSec Remedy <https://infosecremedy.blogspot.com/> >> Blogger at dawidbalut.blogspot.com >> >> 2017-04-10 22:03 GMT+02:00 Eero Volotinen <[email protected]>: >> >>> well. piping shell script to rootshell is not safe even with https .. >>> >>> Eero >>> >>> 2017-04-10 19:59 GMT+03:00 Dawid Bałut <[email protected]>: >>> >>>> Hello Community, >>>> >>>> I noticed that on http://www.openvas.org/install-packages-v7.html >>>> we're encouraging users to wget script from atomiccorp website using http. >>>> As we know this is potential Man in the Middle attack vector, and we >>>> shouldn't spread such bad practice - especially that atomiccorp website and >>>> given resource are available thru https:// so I can't see a reason to >>>> use http. >>>> >>>> So my inquiry is - can you please change in the guide >>>> wget -q -O - http://www.atomicorp.com/installers/atomic |sh >>>> to >>>> wget -q -O - https://www.atomicorp.com/installers/atomic |sh >>>> ? >>>> To make it clear for everyone why I'm concerned by it: >>>> 1. We ask users to fetch it with super user privileges, so if this >>>> request is MiTM'd, it can completely compromise end user machine and for >>>> corporate environments that's a disaster. >>>> 2. We're talking about security software here so we should be a good >>>> example for others. >>>> FYI: The script itself downloads RPM keys via https so in there >>>> everything is fine and the only problem I see is related to the mentioned >>>> instruction in installation guide. >>>> >>>> The scale of the problem is much bigger as I can see the same practice >>>> in here: >>>> http://www.openvas.org/install-packages-v6.html and other wiki pages. >>>> where not only the plaintext wget | sh is encouraged, but also >>>> downloading RPM keys from static URLs is happening via plaintext >>>> HTTP(websites hosting repo keys are in general available with https, so we >>>> should leverage it wherever possible) >>>> Example: >>>> wget http://download.opensuse.org/repositories/security:/OpenVAS: >>>> /UNSTABLE:/v6/Debian_7.0/Release.key >>>> >>>> Appreciate your help and feedback on this. >>>> >>>> Love, >>>> Dawid Bałut <https://www.linkedin.com/in/dawidbalut> >>>> Founder of InfoSec Remedy <https://infosecremedy.blogspot.com/> >>>> Blogger at dawidbalut.blogspot.com >>>> >>>> _______________________________________________ >>>> Openvas-discuss mailing list >>>> [email protected] >>>> https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/o >>>> penvas-discuss >>>> >>> >>> >> >
_______________________________________________ Openvas-discuss mailing list [email protected] https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss
