6 ms·
> Considering that you are a DNS spoof away from installing packages from a compromised server, This is false. Debian packages are signed. If the signature fai
by dmm 8y ago
> Considering that you are a DNS spoof away from installing packages from a compromised server,
This is false. Debian packages are signed. If the signature fails to validate the package will not install.
- isostatic 8y agoWhile this is intuitive and obvious those who have used debian (or rather apt) for decades, it seems that a whole generation of computer professionals don't grasp it. Modern software development involves pulling tons of libraries (often at runtime) from other locations. A lot of damage was done by things like 'sudo pip install xxx' and 'curl http://blah.com/install.sh|sudo http://blah.com/install.sh|sudo bash' At least docker's install uses https before downloading some random text from the internet, nowhere near as secure as gpg signing a package though -- compromise the website and you win.
- eeZah7Ux 8y ago> At least docker's install uses https Anybody with a fake email address can upload a bunch of backdoored images on dockerhub and there's no way to spot that.
- isostatic 8y agoPresumably a given repository is secure? At least as much as a https certificate makes it secure (which means a compromise of a docker certificate or website means a compromise of everything on it) This isn't about downloading random crap from the internet, it's about having the communication between who you trust (redhat, microsoft, dave smith) being secure. GPG signing of the code you download means that you are running the code from the person with that GPG key. Doesn't matter if the server the reporistory is on is compromised via a DNS/https hack, or via some other means. The worst that will happen is you download the compromised software, it doesn't match the person/organization you trust, and you delete it.
- kpcyrd 8y agoThey get their own namespace, they can't overwrite random existing images.
- xenophonf 8y agoRead 'em and weep: https://blog.packagecloud.io/eng/2018/02/21/attacks-against-secure-apt-repositories/ https://blog.packagecloud.io/eng/2018/02/21/attacks-against-... https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.pdf https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.p... "GPG signing a Debian package does nothing because package signatures are not verified by default on any major distribution when packages are installed with apt-get install. See your /etc/dpkg/dpkg.cfg file for an explicit comment to this effect." And: "When APT software (such as apt-get, or reprepro) or folks offering APT repositories mention GPG signatures in their documentation they are typically referring to GPG signatures on repository metadata, not on packages themselves. Likewise, when you configure the SignWith option of reprepro (documented here), you are telling reprepro to sign your repository metadata with the specified GPG key; this does not sign any of the packages, though."
- lamby 8y ago> GPG signing a Debian package does nothing because package signatures are not verified by default on any major distribution when packages are installed with apt-get install That's sliiiiiiightly misleading. :/
- xenophonf 8y agoOn both Debian 9.4 and Ubuntu 16.04 (what I have handy): # Do not enable debsig-verify by default; since the distribution is not using # embedded signatures, debsig-verify would reject all packages. no-debsig
- dmm 8y ago> If the repository is served ... with Acquire::AllowDowngradeToInsecureRepositories set to true(the default is false, thankfully) So you're saying if I explicitly disable an important security feature my system is less secure? No tears yet... That's a good article. It has information relevant to groups setting up apt repositories but the only issue that potentially applies to using the official Debian repositories is the replay attack and that would work even if you were verifying the signatures of individual packages.