[virt-tools-list] [libosinfo] Checksums for driver files

[Christophe Fergeau]

Hey,

On Wed, Dec 12, 2012 at 03:21:27AM +0200, Zeeshan Ali (Khattak) wrote:
> These patches aims to provide applications a way to be able to verify the
> integrity of driver files, which they'll typically be downloading over
> unreliable networks.

This series opens up some interesting questions... If I understand
correctly, you want to check that the files that were downloaded didn't get
corrupt during the download (or that they were not silently corrupted
server-side, ..).

However, what this does not address is checking if the driver we downloaded
is legit. By 'legit', I mean making sure the library user actually
downloaded the file we intended her to download when libosinfo told her to
use
'http://zeenix.fedorapeople.org/drivers/win-tools/preinst/winxp/x86/viostor.sys'
as the virtio-disk driver.
There are various ways for a malicious user to return a different file from
the one we intended (DNS hijacking, hacking zeenix.fedorapeople.org, ...).
As these drivers are then automatically installed in the guest, a malicious
file downloaded this way could do quite some nasty things. Let's call this
issue #1.

Another vector I'm worried about is the fact that by default we load
database data from ~/.config/libosinfo/db after the system data. This can
probably be abused by overriding Windows installation info and pointing
it at drivers on a totally different server. I'll call this issue #2.


Your patch series would address issue #1 as the file checksums will be
hardcoded in the system libosinfo database. We need to use something
different than md5 though if we want to rely on that as this has known
collision vulnerabilities. This does not address #2.

And even that validation will probably break once we add a way to download
updates to the libosinfo database from the net as the db updates could be
compromised in the same way, with the drivers URLS/sha256sum changed to
point to malicious drivers.

One way of addressing these issues would be to add GPG signatures alongside
each file we want to download, and hardcoding the known keys in libosinfo
binary.
Other options could be to only validate DB updates in such a way, or to not
allow install-scripts and related data to be overridden by the user/remote
updates (didn't give a lot of thoughts to that).


The reason I'm bringing that up now is that this seems to me more worrying
than checking that the file was not corrupted doing download, and, depending
on which way we want to go to solve these problems, the solution may be
redundant with what this series does (ie checking that the files are legit
would also guarantee that they were not corrupt during download).

Thoughts?

Christophe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20121212/7d4b4a02/attachment.sig>