Hi. Some time ago, I've wrote several bug reports to packages, that download files from some non-apt-secured sources of the web, and install them.
I got more or less positive feedback from maintainers that happily accepted my suggestions, to those who thought they were crap and not necessary ;) Some days ago Tom Feiner opened #546945 (and CC'ed) me, which proved me that I'm not the only one concerned about this issues. So I thought it might be worth to bring them up for discussion here. CURRENT SITUATION: One can differ between three classes of packages: 0) Packages who do not download anything from the web. 1) Packages which download stuff but this is just normal data like pidgin, firefox (I mean html here, not plugins), wget,.. 2) Package installation already downloads something and installs this e.g. some font packages (msttcorefonts) or documentations (susv2/3) do this. 3) The package provides automatic update scripts (like here), where content that in principle belongs to the package is replaced/updated. Many packages do this (clamav-freshclam, rkhunter, tiger, some packages for firmwares) Of course we cannot secure case 1. But we should cover 2 and 3. WHAT I'D SUGGEST: On class (2): Here it is really important. The end-user does not know in advance that such a package behaves like this. He thinks that he just gets debian-apt-secured stuff. I think susv2 and susv3 was an example of such a package, that did not any checksumming (no I do not want to blame the maintainer here, actually I like these packages very much): Although this is just documentation, it adds some space that could be used by attackers (malicious HTML code, PNG files, etc.) Those packages should include hashsums of the downloaded files, verify them and if they don't match: - the installation should fail (leaving the package in a broken state) - the pre/postinst should remove all data that was downloaded (and that is potentially compromised). I'd even suggest that this should be enforced by the policy. The policy should also mandate a "good" hash-algo,.. at least SHA-256, I'd say... On class (3): Here it's difficult. I'd say the following: If the package does this downloading and installing automatically (or mostly automatically),... it should be REQUIRED to do this via checksumming (hashes added to the update scripts). Examples for this can be clamav-freshclam, rkhunter. If the user really manually invokes some command e.g. update-rkhunter-db or so,.. it just SHOULD do this checksumming. POTENTIAL PROBLEMS: As we see all this is doable; we already have quite a number of packages, which perfectly check hashes, and fail installation if they don't match. It gets however difficult if the data to be secured changes very often... For clamav-freshclam it's practically impossible for the maintainer to provide debian-apt-secured packages with new hashes in time (btw: I don't know if clamav already does some "internal" verification). For such packages one should contact upstream, and ask them to add such a functionality. As the clamav exmaple shows (if it does not already verification) it can be a security threat, if the virus-definitions are not signed.... => an attacker could simply remove the definitions from the viruses he want's to use. The same is the case for the rkhunter weekly DB update example. WHO SHOULD "CONTROL" THE HASHES/SIGNATURES?: Apart from those volatile stuff, definitely the Debian maintainer. What do I mean here? I'll try to give an example: There's the flashplugin-nonfree package which downloads the most recent version. If adobe would provide own signatures (e.g. GPG) the package could simply use this, to do the checks. The problem is then of course,.. that Adobe has the power of what can go in and what not. I'd suggest, that the maintainer uses the Adobe-key to verify the files, from which he's creating hashes, that are going into his packages (for later verification). FOR CLOSED SOURCE STUFF,... IS IT WORTH AT ALL?: In the flashplugin example form above, I've suggested, that Debian should keep the control over the sigs. But one could even ask if verification in such a closed source thingy is it worth anyway? I'd say: Definitely yes. Although no one can read the source code of those plugin (to tell whether it has backdoors or not ;) )... we can at least secure that ALL users have the same binaries of it. Thus we prevent single users from being attacked by forged versions. Even if the maintainer itself would have created the hashes from a forged version,.. we'd probably all notice very soon (as the verification fails for the rest of the world). Of course,.. if the attacker managed to replace the upstream version by his forged one... we're still screwed. Of course all the above could mean more or less effort (depending on the specific case),.. but at least it's good to start discussion. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
