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

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



On Wed, Dec 12, 2012 at 5:43 PM, Christophe Fergeau <cfergeau redhat com> wrote:
> On Wed, Dec 12, 2012 at 04:41:03PM +0200, Zeeshan Ali (Khattak) wrote:
>> On Wed, Dec 12, 2012 at 12:31 PM, Christophe Fergeau
>> <cfergeau redhat com> wrote:
>> > Hey,
>>
>> Hi,
>>
>> > 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.
>>
>> Only if the app chooses to do so (fwiw, Boxes doesn't do that).
>
> Are you sure? osinfo_loader_process_default_path() loads user data, and
> Boxes calls this.

Then I remembered wrong. Thing is that we load our (Boxes) custom
logos db explicitly so that confused me..

>> > 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.
>>
>> I should have explained better. The main rationale for checksums was
>> to check if file got corrupted or not during download. #1 is more of a
>> side-affect. TBH, security wasn't my concern with these patches.
>
> Yes, this was my feeling as well (that they were not aimed at security).
> However these patches probably overlap with making this stuff more secure,
> and depending on how we choose to achieve this, they may be redundant/need
> adjustments, that's why I'm wondering what we want to do there.

After talking to Daniel on IRC about this, I agree with him that
properly addressing all security issues would be pain and we really
have better things to do right now. Checksums already address the
issue #1 so recommend we go with this approach for now.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124


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