oss-sec mailing list archives
Re: CVE for Kali Linux
From: Donald Stufft <donald () stufft io>
Date: Sun, 22 Mar 2015 14:15:32 -0400
On Mar 22, 2015, at 1:55 PM, Kurt Seifried <kseifried () redhat com> wrote: On 03/22/2015 11:23 AM, 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.The problem is to do this you need some key/shared secret/verifiable secret, e.g. a GPG key. How do I get the GPG key securely? In reality most system, for better or worse, ship with a set of certificate roots that can be used (in theory) to prove the validity of a web site. Hence the HTTP vs HTTPS debate. Sadly, HTTPS is the best we have for that initial bootstrap often. My personal thought on this is the same reason I sign all my email. I don't sign my email for security reasons, so much as to prove the validity of the key, e.g. at this point either I truly am keifried () redhat com or someone has been impersonating me for so long and getting away with it, they might as well be me. So in the case of an ISO download that is GPG signed how do I verify the key is correct? If this is all done over HTTP it is pretty trivial for an attacker to run a Man in the Middle proxy that string replaces they key/signature as needed. HTTPS significantly raises this bar, it goes from "run off the shelf Squid/etc" to "convince a CA to give you a wonky certificate".I don't care about CVEs much, but if CVEs start being assigned to anything like this, they should be for lack of signatures or lack of signature verification in the vendor's recommended software installation or update mechanism or lack of a way to verify the signing key or lack of key verification in the vendor's recommended procedures (where applicable). (With key verification, it gets tricky. So probably those issues are not CVE-worthy yet, except in extreme cases where e.g. new signing keys would be downloaded automatically with no verification.)That is what we have done in past, however in this case my question is still "if a vendor provides a download securely, but then advises people to do something really insecure, does that win a CVE”.
To be clear, I have a massive +1 on getting anything behind HTTPS, but IIRC CVEs are only for vulnerabilities in software that get distributed? In other words, the lack of HTTPS on a particular site is not a CVE worthy issue, but if some software that connects to HTTPS sites doesn’t verify the TLS then that is a vulnerability? The line does get grey in the terms of tooling designed to interact with a particular domain that does not have HTTPS enabled. However in a more pertinent note, it looks like Kali Linux downloads are hosted over HTTPS with SHA1 digests (which are signed by GPG), when I clicked on the link to actually download them I was taken to: https://www.kali.org/downloads/ So it sounds like in this case the docs that the thread originally started with are likely just outdated? There’s SSL stripping issues of course, since the docs themselves are not hosted via HTTPS someone can MITM those to rewrite the instructions to point to somewhere else… but that quickly starts getting into the weeds in terms of a CVE-worthiness.
They should not be for use of http, nor for https vulnerabilities. https does offer a security aspect that signatures don't: it hides from some observers which exact software is being downloaded (and maybe that it's a software download at all). It doesn't do that perfectly because the target address and transfer timings and sizes may be revealing, but I do acknowledge there's some subtle improvement over http here. I just think this is far less important than ensuring authenticity of the software. So let's demand signatures and signature verification first, and let's not be distracted by http vs. https.How do you propose we bootstrap secure key distribution and verification then? This is a real world problem with no easy solution.Alexander-- Kurt Seifried -- Red Hat -- Product Security -- Cloud PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
--- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
Current thread:
- Re: CVE for Kali Linux, (continued)
- Re: CVE for Kali Linux Daniel Micay (Mar 22)
- Re: CVE for Kali Linux Michael Samuel (Mar 21)
- Re: CVE for Kali Linux Florian Weimer (Mar 22)
- Re: CVE for Kali Linux Kurt Seifried (Mar 22)
- Re: CVE for Kali Linux Jeremy Stanley (Mar 22)
- 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)