Re: CVE for Kali Linux

[Kurt Seifried <kseifried () redhat com>]

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".

> 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

Attachment: signature.asc
Description: OpenPGP digital signature