Re: [Qemu-devel] [PATCH RFC 2/2] block: Warn on insecure format probing

[Kevin Wolf]

Am 31.10.2014 um 23:45 hat Eric Blake geschrieben:
> On 10/30/2014 06:49 AM, Markus Armbruster wrote:
> 
> > You either have to prevent *any* writing of the first 2048 bytes (the
> > part that can be examined by a bdrv_probe() method, or your have to
> > prevent writing anything a probe recognizes, or the user has to specify
> > the format explicitly.
> > 
> > If you do the former, you're way outside the realm of "theoretical".
> > 
> > If you do the latter, the degree of "theoreticalness" depends on the
> > union of the patterns you prevent.  Issues:
> > 
> > 1. Anthony's method of checking a few known signatures is fragile.  The
> > only obviously robust way to test "is probing going to find something
> > other than 'raw'?" is running the probes.  Feasible.
> > 
> > 2. Whether the union of patterns qualifies as "theoretical" for all our
> > targets is not obvious, and whether it'll remain "theoretical" for all
> > future formats and target machines even less.
> 
> This one scares me.  The proof of concept patch you posted tests whether
> a write to the first sector would result in the sector matching a
> _currently known probe_ for the file formats that were compiled in at
> configure time to the currently running binary.  But this is NOT the set
> of all possible binary formats that may be introduced in the future.  By
> extrapolation, if we pursue write blocking, then the only SAFE way to is
> to reject ALL writes to the first sector, because we can't know which
> writes will match some theoretical future probe - but by the time you
> get to that point, then we no longer match bare metal (rejecting ALL
> writes to the first sector is ridiculous).

There is no absolute security without forbidding raw. Who says that the
next format doesn't have its magic in sector 42?

You are right that if an attacker knows which new format supporting
backing files we'll have in the next version, and the user uses probed
raw despite the warning (which means they are not using libvirt), the
attacker can write the header of the new image format now and hope that
the user leaves it alone until the update happens at some point in the
future. Then the malicious guest can access that one file, but not
obtain access to the next one (because the new checks are in place
then).

I don't think this is a relevant attack vector. It's probably much
easier to get the user to run an untrusted image than converting a
trusted image into a time bomb and waiting potentially for months or
years for it to explode.

Kevin

pgpQws4kzrMtj.pgp
Description: PGP signature