Apt CVE-2020-3810

Apt got a security fix for an out of bounds access bug when processing malicious .deb archives. I think a point release that includes the fix is needed.


@Patrick let me know when I can build a branch that carries the new packages.

1 Like

That doesn’t sound very bad. Malicious deb can also include malicious files and/or malicious maintainer scripts as per discussion on github link above.

This doesn’t need any change from me. Builds currently by default always with APT packages.debian.org as up to date as Debian provides them. No more frozen packages.debian.org for now. In other words, if you build 2 weeks ago, then it uses Debian packages.debian.org from two weeks ago. If you build today, it uses Debian packages.debian.org from today.

What would need me to push upgrades is deb.whonix.org and deb.torproject.org (download and re-upload to deb.whonix.org).

Related, latest tester-only release:
Whonix VirtualBox - Testers Wanted!

1 Like

The vuln is triggered as soon as apt parses it before any sig is checked.

1 Like

apt doesn’t parse deb’s normally. dpkg does. apt parses repository metadata.

When running “sudo apt install /path/to/deb” this could be an issue but in that case that package will get full control over the system anyhow.

The two Debian developed in that thread say:

But well, the places were we read debs we are not really concerned about security anyway. We have either validated the hashes and/or you are about to install a random 3rd party deb anyway, so they’re going to get maintainer scripts running as root anyway, so meh.

apt itself doesn’t concern itself with reading deb files in the normal case, it is used by apt-ftparchive, apt-extracttemplates and by every apt command accepting an explicit deb file in place of a packagename – all of which should be dealing with reasonable files as you are about to do things far worse than illegal memory access. So it isn’t strictly needed, but defense in depth, users do silly things and all that.

1 Like

Thanks for diving into this.