On 2024-11-08 04:04:19 +0000 (+0000), debianmailinglists.hz5zm@simplelogin.com wrote: > I'm not a Debian developer, just a curious onlooker who hasn't > seen all of these messages, so I could completely off base with my > understanding of how things work. But, it was my understanding > that the bundled MD5 inside a .deb file isn't there for security, > it's just there to make sure the packages arrived in one piece and > weren't corrupted, and for that purpose it's still perfectly > adequate. The "security", or validity of the packages' origin, are > ensured by the digital signature on the packages or repos. A > malicious package forged to match a desired MD5 would still fail a > digital signature check. > > Am I incorrect in how this all works? [...] Mostly. I don't know that the per-file checksums inside the DEB are all that useful to "make sure the packages arrived in one piece and weren't corrupted" since we already have stronger solutions for that: Starting from the top, first have a look at the content of https://deb.debian.org/debian/dists/bullseye/InRelease (it's plain text) and you'll see that the distribution index contains a list of all package indices with their sizes and *both* MD5 and SHA256 checksums (scroll down to get to the latter). The whole of that is inline-signed with an OpenPGP key which gets verified against your secure APT keychain. Now drill down into, say, https://deb.debian.org/debian/dists/bullseye/main/binary-all/Packages.xz (also text, but you'll need to decompress it of course) and you'll see that each package listed there has both a MD5sum and SHA256 field. So basically, any alterations to a package should be detectable as a SHA256 checksum mismatch already, alterations to the list of package checksums detectable as a SHA256 checksum mismatch in the release file, and changes to the checksums in the release file detectable by causing the OpenPGP signature to fail validation. The main things this doesn't cover are possible changes to your installed files on disk, or cases where you manually downloaded a DEB outside the above chain of provenance and installed it. Now grab a package file like https://deb.debian.org/debian/pool/main/o/openssh/ssh_9.9p1-3_all.deb and unpack it (dpkg-deb ssh_9.9p1-3_all.deb foo) and take a look in the foo/DEBIAN/md5sums file. Here there's only MD5 checksums, so if you *wanted* to check your installed files against the list of per-file checksums from the package (e.g. with the debsums utility), then yes it's only able to rely on MD5 for that today. As previously discussed, MD5's lack of collision resistance isn't a serious concern for this use case because any actual attack which kept the checksum valid would require cooperation from whoever created the initial file to make sure it could have such a collision at all. There's the start of a plan outlined in https://wiki.debian.org/Sha256sumsInPackages from almost 15 years ago which didn't get a lot of traction, and most of the bugs you'll find linked there were eventually closed for inactivity. However, a comment in https://bugs.debian.org/540215 suggests that an redesign of the DPKG database is planned to introduce manifests for DEBs where a more modern hash could possibly be implemented for per-file integrity checking. You can find the new specification at https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking though it doesn't explicitly mention any changes to the checksum algorithm (I gather that would have to come later, as a separate effort). If someone is really uncomfortable checking installed files solely against MD5 hashes though, there's always the option of unpacking the original packages and generating your own checksums with any algorithm of your choosing, of course. There are also a slew of host intrusion detection tools already available to monitor files for unexpected alteration as well, which wouldn't need to rely on MD5sums from the DEBs anyway and could generate whatever sorts of checksums they wanted instead (hopefully stored and compared remotely, since an attacker who can change arbitrary files on your system could also just alter the checksum database while they're at it!). -- Jeremy Stanley
Attachment:
signature.asc
Description: PGP signature