[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 22 Mar 2015 14:15:32 -0400
From: Donald Stufft <donald@...fft.io>
To: oss-security@...ts.openwall.com
Subject: Re: CVE for Kali Linux
> On Mar 22, 2015, at 1:55 PM, Kurt Seifried <kseifried@...hat.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@...hat.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
Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
