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

[Kevin Wolf <kwolf@redhat.com>]

Am 04.11.2014 um 10:36 hat Markus Armbruster geschrieben:
> Kevin Wolf <kwolf@redhat.com> writes:
> 
> > 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?
> 
> Correct.
> 
> > 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.
> 
> The threat from using untrusted images with embedded filenames is real.
> 
> Regardless, I wouldn't discount the (different) threat from guests
> exploiting "future" probes so cavalierly.  If your host is running a
> stable distro, its future is easy to know.  Even the point of time when
> it gets upgraded can be predictable.
> 
> In general, I recommend against leaving security holes in place just
> because you think nobody could be bothered to exploit them :)
> 
> Security is not an absolute that cannot be trumped by any other
> consideration.  I'm perfectly happy to consider usability and
> compatibility issues, as well as implementation complexity.  I'm much
> less willing to accept a "come on, nobody is going to try *that*"
> argument.

No, I didn't mean to make a "come on, nobody is going to try *that*"
argument.

I just can think of more attacks that we won't avoid with either
approach. For example, what if another program on the host is
exploitable and you just need a file with the right content to attack
it? A raw image gives you what you need. Nobody is going to try *that*
then, if you're content with allowing this?

The only full solution is forbidding raw. We have already agreed that
this isn't an option. Now we have to draw a line somewhere.

Kevin