Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)
On Sun, Oct 23, 2016 at 7:23 AM, Eugene V. Lyubimkin <firstname.lastname@example.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
* 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