[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Packages that download/install unsecured files


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.

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

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.

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.

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
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.

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
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).

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.


Reply to: