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
-----BEGIN PGP SIGNATURE-----
iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmcuMR5fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WCm34xAAnb6rcOSwTyoESYYg/vvGNi2hrgYNCFzeXbEnr+jDqzFrBruxHil6tT9/ jA89W8LRZYh7tfFJeMnG8rwAw/MffcwKG8rasLsuvi3wApqSmjKAV/RBqo+MBj1A MTBKxIQaY5wIhXj7PLLI8QFmsmw7qc61W6vS4y9HTtIG18JqUoo/olTpoUIT0fNf mKhsLbFa0T46vRo/lS/MRXsXx7K6ffgbCL/gPDpLLCyEeljtql22DWTiVHt7UACi OtNLcSy2EEammSuSHhiKLvn7uY0FfCZuYsop4UAdR2Y0yiOtBtYZRGIJFOjMM5Q2 BpF9kepH7Ta+ugRg+gDr7PRr3HQVABIXAQG2B5orQx3ygZzk9HmDDQC2jOkt6Au1 BRoOaR4C1Qye/yo59WfTmKLmK7aI8hBnCxQbRHqrvB4C2qZtdB3YM2i2Vbl/XD09 7CZV3XAQpbttdf9WD6d+tRWZAzUHFnZqZZHmeWeP/FaKw+9p+SBaTcyGjZ7BRXo0 yCRxYMX0w6JCqGdHKXJOePywXGvPVB5HllXZeMorKE4XGmMSrzCbTk2k2EycKlnz V1wmSfwsDlnpl5EhLI9jnPwbvgyN3QZvKl4i1GmgDHgmesr+nWf1qKrMqU2mDryR F+8Tp1kML61PK/7J2e61wHDjAtCYEsp/z991Azpn+IlTjOZooTQ=
=Z9sY
-----END PGP SIGNATURE-----
--- SoupGate-Win32