Böck: Multiple vulnerabilities in RPM – and a rant

Posted Aug 30, 2016 10:06 UTC (Tue) by Darkmere (subscriber, #53695)
In reply to: Böck: Multiple vulnerabilities in RPM – and a rant by niner
Parent article: Böck: Multiple vulnerabilities in RPM – and a rant

That's pretty much my point.

apt (not dpkg) only signs the list of hashes of all packages.

There is no signature on the metadata of each package, which means that the list of sizes, permissions, and checksums are not signed.

So you can't go from "I have foobar-1.0_4.deb installed", to "Is it possible to verify that the files I have are the ones that Debian shipped?"

in an RPM package, the metadata is signed for each package. In deb, dpkg doesn't even support signatures, that's all done on the APT-layer. Officially, this is to be able to revoke signature on a file.

Unofficially it seems to be designed to make it easier to backdoor Debian & Ubuntu systems.

Böck: Multiple vulnerabilities in RPM – and a rant

Posted Aug 30, 2016 20:24 UTC (Tue) by BenHutchings (subscriber, #37955) [Link] (7 responses)

You can't test for "has this system been maliciously modified" while running the system. Any good rootkit should tell you no, everything's fine! You have to take the system offline and mount the disk somewhere else, to verify its files.

There is a small advantage that signed packages get you here, which is you could maybe pull the original package out of a cache on the suspect system and verify its signature before using it as a reference. Without package signatures, you would have to download it again from a trusted archive. Is that what you're getting at?

Böck: Multiple vulnerabilities in RPM – and a rant

Posted Aug 30, 2016 20:45 UTC (Tue) by Darkmere (subscriber, #53695) [Link] (3 responses)

With a proper chain of metadata + signatures you can verify it:

package contains a list of filenames + hashes + metadata
package contains a signature blob of above list
package manager then saves this in the database

File contents can be validated by the hash, integrity of the list of the hashes can be verified by itself.

The problem is that on a given debian system, you cannot go from "this package is 1.1_deb33" installed, and come to the answer of the question "Have it's files been maliciously tampered with".

There is no historical list of these signatures, once a new package is uploaded to the debian mirrors, you cannot verify any older package.

There is also no policy of not fucking around with the contents of binaries on disk -after they have been installed- by either this package, or some other package. It happens quite often that post/pre-install scripts start to mess with the files on disk.

The reasoning that Debian choose to blame was the fact that "an older package that contains serious bugs should not be trusted if a new has been published". A false claim if any ( you could simply not trust the on-file signature for installation purpose. )

What frustrates me is that once a system is no longer 100% up to date, you cannot validate that the files you have installed are unmodified.

Böck: Multiple vulnerabilities in RPM – and a rant

Posted Aug 30, 2016 21:22 UTC (Tue) by BenHutchings (subscriber, #37955) [Link]

File contents can be validated by the hash, integrity of the list of the hashes can be verified by itself.

That sounds quite good, though its usefulness depends on exactly what's being hashed. (For example, does the signed hash include the package name and version?)

There is no historical list of these signatures, once a new package is uploaded to the debian mirrors, you cannot verify any older package.

That's not longer true for at least Debian, since historical packages and the corresponding signed package indexes are accessible through snapshot.debian.org. However it's not a totally straightforward procedure to download and verify a binary package from there (and the debsnap tool doesn't), let alone to check all the packages supposed to be installed on a suspect system.

Böck: Multiple vulnerabilities in RPM – and a rant

Posted Sep 2, 2016 14:29 UTC (Fri) by yoe (guest, #25743) [Link] (1 responses)

You're wrong when you say "you cannot verify any older package". This is why http://snapshot.debian.org/ exists.

Böck: Multiple vulnerabilities in RPM – and a rant

Posted Sep 4, 2016 11:48 UTC (Sun) by Darkmere (subscriber, #53695) [Link]

Which _only_ works if you're 100% upstream in debian, on a _very_ debian specific solution.
Not a part of the package management tools.

And as someone elsewhere stated, apparently dpkg does support signed binaries, just that Debian doesn't use it.

Debian, when given two choices would make two optional and a third mandatory.

Böck: Multiple vulnerabilities in RPM – and a rant

Posted Aug 30, 2016 21:19 UTC (Tue) by lsl (subscriber, #86508) [Link] (2 responses)

I don't think malicious modification is the main usecase for that. Like you say, you can't tell anything at all from within the running system.

There are other kinds of unwanted modification, like accidental corruption. Think of running "make install" where the Makefile unexpectedly defaults to a prefix of /usr. Or the unbounded joy of things like pip/rubygems/… happily blowing away system packages.

That's where rpm -V style verification can be very useful.

Böck: Multiple vulnerabilities in RPM – and a rant

Posted Aug 30, 2016 22:03 UTC (Tue) by BenHutchings (subscriber, #37955) [Link] (1 responses)

And that's exactly what dpkg -V also does. Although checksums are not a core feature of the format, but most deb packages include them and if the debsums package is installed it will generate any missing checksums at install time.

Böck: Multiple vulnerabilities in RPM – and a rant

Posted Aug 30, 2016 22:20 UTC (Tue) by guillemj (subscriber, #49706) [Link]

Starting with dpkg 1.16.3, md5sums files will be generated automatically at unpack time and stored into the dpkg database if they are not present in the .deb. debsums is pretty much obsolete these days.

Böck: Multiple vulnerabilities in RPM – and a rant

Posted Aug 30, 2016 22:26 UTC (Tue) by guillemj (subscriber, #49706) [Link]

dpkg has supported signed .deb for a long time (since dpkg 1.9.0) via the debsig-verify package (check also the --no-debsig dpkg option in /etc/dpkg/dpkg.cfg). You can sign them with the debsigs package. Debian just does not use signed .deb packages, it uses signed repository indices.