oss-sec mailing list archives
Re: CVE for Kali Linux
From: Daniel Micay <danielmicay () gmail com>
Date: Sun, 22 Mar 2015 14:33:01 -0400
On 22/03/15 01:23 PM, Solar Designer wrote:
On Sun, Mar 22, 2015 at 12:54:57PM -0400, David A. Wheeler wrote:On 2015-02-26 I reported to Cygwin that they had a similar man-in-the-middle issue. The Cygwin package manager (which downloaded all other packages) was unprotected and downloaded using http (as http://cygwin.com/setup-x86.exe or http://cygwin.com/setup-x86_64.exe). They changed it to load with HTTPS, and later added HTTP Strict Transport Security (HSTS).IMO, http vs. https is a red herring. We shouldn't be focusing on security of software downloads, but rather on authenticity of the software. If the distribution web server gets compromised, https doesn't help. Thus, GPG signatures and the like.
This works well for securing upstream <-> distribution <-> user because it's handled behind the scenes. The distribution verifies the upstream signature and then the packages produced from it are signed with a key trusted by the distro's keyring. If the web server is compromised or the attacker can do a MITM, they can provide whatever instructions they want to the users. That's all it takes. The attacker could add a news item stating that there's a new GPG key because the dev's laptop was lost. How many users are really going to question that? This stuff happens all the time. The web of trust and key revoking works well in controlled situations but not for end users. HTTPS/HSTS/HPKP is important because it doesn't require that the user goes out of their way to validate the software (few do) and is needed to build the initial trust in the first place. How else do you get the GPG public key in the first place? ---- Here's a case study: a user wants to install Debian. They are on some OS that's not Debian. They search for it and head to www.debian.org. It does not use HTTPS preloading, so they could now be seeing an HTTP page controlled by an attacker. Lets say they use HTTPS Everywhere so this can't happen if the attacker can't create a valid cert. Someone with control of a root certificate would be defeated by HPKP but of course that's far bigger thing to expect than just HSTS. They now click the network installer download in the top right of the main page. This uses HTTP, and there are no instructions to verify it in any way and no link to a signature. The page is HTTPS and there is no clear indication that this download was not - I would have assumed it was HTTPS because I trust Debian enough to have that expection. If they had gone to either of these links to get the net install, it would not have been any different: https://www.debian.org/distrib/ https://www.debian.org/distrib/netinst The installation guide does *not* tell them to validate anything. If they headed to the CD page, they may have found the verification page. It's on the sidebar to the right and it's mentioned that they are signed: https://www.debian.org/CD/ The verification page tells them to use the Debian keyring, which they do not have: https://www.debian.org/CD/verify There are no instructions on how to verify it anyway. However, lets say the user is already an experienced GPG user and either fetches these keys via the fingerprint or validates the fingerprint after using the keyd id to fetch. They download the signed hashes, validate the signature (why isn't the ISO itself signed anyway?) and validate that the ISO has the correct hash. They then go on to install Debian and get the Debian keyring as part of the installation. It was hard to discover the availability of signatures and the need to verify them was presented as just an unimportant optional task. It was not documented so it required prior experience / proactive research elsewhere. It relied on the existing HTTPS authentication to retrieve the correct keys. At best, GPG offered *zero value* compared to checking a hash provided via HTTPS, grabbing a torrent file via HTTPS or downloading directly via HTTPS. However, I think it's pretty clear that few users would have gone through with this and all it did was maintain the same security offered by the HTTPS PKI. The user obtained the keyring from the ISO as part of the installation and Debian's trust model works well from that point onwards. ---- Anyway, how is HTTPS not incredibly important here? Even an experienced Linux user is screwed in this model. This is also how things usually go when a user wants to obtain software that's not in the repos. In some cases, upstream happens to be something like the Tor project and they have HTTPS+HSTS+HPKP along with links to signatures right next to the downloads and a link to a clear explanation on how to use them. Users who make use of the signatures will be more secure as a hack of the server won't compromise them, but the vast majority who don't do this still have authentication up to that point.
Attachment:
signature.asc
Description: OpenPGP digital signature
Current thread:
- Re: CVE for Kali Linux, (continued)
- Re: CVE for Kali Linux Kurt Seifried (Mar 22)
- Re: CVE for Kali Linux David A. Wheeler (Mar 22)
- Re: CVE for Kali Linux Solar Designer (Mar 22)
- Re: CVE for Kali Linux Solar Designer (Mar 22)
- Re: CVE for Kali Linux Kurt Seifried (Mar 22)
- Re: CVE for Kali Linux Donald Stufft (Mar 22)
- Re: CVE for Kali Linux Daniel Micay (Mar 22)
- Re: CVE for Kali Linux Kristian Fiskerstrand (Mar 22)
- Re: CVE for Kali Linux Jeremy Stanley (Mar 22)
- Re: CVE for Kali Linux David A. Wheeler (Mar 22)
- Re: CVE for Kali Linux Daniel Micay (Mar 22)
- Re: CVE for Kali Linux Stephen Kitt (Mar 22)
- Re: CVE for Kali Linux Daniel Micay (Mar 22)
- Re: CVE for Kali Linux Alexander Cherepanov (Mar 22)
- Re: CVE for Kali Linux Alexander Cherepanov (Mar 22)
- Re: CVE for Kali Linux Russ Allbery (Mar 22)
- Re: CVE for Kali Linux Solar Designer (Mar 22)
- Re: CVE for Kali Linux Russ Allbery (Mar 22)
- Re: CVE for Kali Linux David A. Wheeler (Mar 22)
- Re: CVE for Kali Linux Alexander Cherepanov (Mar 23)
- Re: CVE for Kali Linux Alexander Cherepanov (Mar 23)