On Thu, 24 Jan 2019 00:58:27 +0100 KatolaZ <[email protected]> wrote:
> On Thu, Jan 24, 2019 at 12:28:35AM +0100, Florian Zieboll wrote: > > Am 23. Januar 2019 23:54:10 MEZ schrieb KatolaZ > > <[email protected]>: > [...] > > > > 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
pgpRj7hLJxC9F.pgp
Description: OpenPGP digital signature
_______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
