[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <550F0ADD.5020800@gmail.com>
Date: Sun, 22 Mar 2015 14:33:01 -0400
From: Daniel Micay <danielmicay@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE for Kali Linux
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.
Download attachment "signature.asc" of type "application/pgp-signature" (820 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.
