On Thu, 24 Jan 2019 00:58:27 +0100
KatolaZ <katolaz@???> wrote:

> On Thu, Jan 24, 2019 at 12:28:35AM +0100, Florian Zieboll wrote:
> > Am 23. Januar 2019 23:54:10 MEZ schrieb KatolaZ
> > <katolaz@???>:
> [...]
> >
> > Hallo Katolaz,
> >
> > thank you for the quick clarification, I got it and was just about
> > to write a follow up mail. Do IUC, that without tls it is still
> > possible to mount a MITM?
>
> Dear Florian,
>
> the presence of TLS won't help a bit to avoid the apt bug we are
> referring to. First because the bug is in the way the "Location:"
> header is parsed, which has nothing to do with the fact that you do or
> do not redirect to an HTTPS URL. Second, because the vulnerability is
> not about a MITM attack, rather a remote exploit.
>
> No MITM attack to the Debian/Devuan repo can be easily mounted, since
> packages are checksummed, and all the checksums are signed with the
> repository key (it's just a tiny bit more convoluted than that, but
> still). So if any package is out of order (i.e., it presents a
> checksum that offends the signed one), apt will immediately discover a
> mismatch with the signed and verified material, will refuse to
> continue, and will exit *loudly* (i.e., with an ERROR)OB.
>
> HTTPS won't add a single bit of security to a Debian/Devuan repo. It
> will exclusively avoid an external actor to see which packages are
> actually requested and downloaded by the client.
>
> My2Cents
>
> KatolaZ


This contradicts the original bug report as I understand it:

| The parent process will trust the hashes returned in the injected 201
| URI Done response, and compare them with the values from the signed
| package manifest. Since the attacker controls the reported hashes,
| they can use this vulnerability to convincingly forge any package.

and

| But apt’s signature validation process is totally fine with the
| presence of other garbage in that file, as long as it doesn’t touch
| the signatures. So I intercepted the Release.gpg response and
| prepended it with my malicious deb

(Source: https://justi.cz/security/2019/01/22/apt-rce.html)

As the integrity of the release file should be verified by the not
redirected 'apt update' command, I suggest that the following example,
with the pkgmaster.devuan.org/merged/ repository, be "waterproof" in
context of the thread's subject - or did I miss something?

    $ apt -o Acquire::http::AllowRedirect=false update
    $ wget https://pkgmaster.devuan.org/merged/pool/DEBIAN-SECURITY/updates/main/a/apt/apt_1.4.9_amd64.deb

then compare the output of

    $ sha256sum | sed -e 's/\ .*$//'
    $ apt-cache show apt | sed -n 's/SHA256: //p'`

if it matches, install with

    $ dpkg -i apt_1.4.9_amd64.deb

and repeat for apt-utils, libapt-pkg5.0 and libapt-inst2.0

Florian