[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)

Hi :)

On Sun, Oct 23, 2016 at 7:23 AM, Eugene V. Lyubimkin <jackyf@debian.org> wrote:
> I'm a developer of a tool which downloads and validates Debian archives
> in a similar way APT does.
> As you use the word "theoretically", that suggests that practically
> one can bypass the validation. Could you please list all numerous ways
> to bypass it, so we'd fix our software?

I will detail more recent issues in the future, but just to start:

* Numerous attacks against the downloading client itself (buffer
management flaws to gain code exec, etc)

* Attacks against a GnuPG client parsing public keys or validating signatures
** CVE-2014-4617
** CVE-2013-4402
** CVE-2013-4351
** CVE-2006-6235
** CVE-2006-0455
** CVE-2006-0049
** CVE-2001-0071

* Attacks against weak pre/post-install scripts that retrieve network
data over HTTP

* If your GPG private key is compromised (factored or stolen) without
your knowledge, HTTPS+HPKP helps make arbitrary targeting / infecting
of users much more difficult.

* Potentially trick APT into thinking the install is coming from media
disc and bypass Release file signatures

* If a user adds a GPG key for another third-party product repository
(eg. oracle-java) and that key was generated by NSA to appear as a
legitimate package, HTTPS+HPKP prevents NSA from tampering core
packages too easily (since they have the private key that likely many
users have trusted).

* If a user downloads a GPG public key by searching the public key
servers, NSA can potentially exploit CVE-2012-6085 to overwrite the
trusted local GPG store for trusted keys with a key store of their
choosing. Or also CVE-2008-1530.

* CVE-2012-3587 / CVE-2012-0954 -- APT 0.7/0.8, when using the apt-key
net-update to import keyrings, relies on GnuPG argument order and does
not check GPG subkeys, which might allow remote attackers to install
Trojan horse packages via a man-in-the-middle (MITM) attack.
HTTPS+HPKP would have made this much harder.

* More PitM attacks via CVE-2009-1358 -- "apt-get in apt before 0.7.21
does not check for the correct error code from gpgv, which causes apt
to treat a repository as valid even when it has been signed with a key
that has been revoked or expired, which might allow remote attackers
to trick apt into installing malicious repositories."

* Potentially attack NTP to change the date on a targeted Debian
client system in order to cause potentially exploitable exceptions for
use in a package tampering attack shortly thereafter.

There are other attacks too, but this should suffice for now? I think
the synopsis here is to leverage HTTPS to minimize the exposure from
APT, GPG, parsing / related bugs...unless you truly believe that
programs interpreting untrusted data over HTTP is 100% securely
constructed (quite unlikely).


Kristian Erik Hermansen

Reply to: