qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Image probing: how it can be insecure, and what we coul


From: Markus Armbruster
Subject: Re: [Qemu-devel] Image probing: how it can be insecure, and what we could do about it
Date: Mon, 10 Nov 2014 09:13:18 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Markus Armbruster <address@hidden> writes:

[...]
>                let me refine / vary the hybrid approach I mentioned
> under " Don't guess format from untrusted image contents" some.  I think
> I can trace some inspiration to Max here.
>
> Say we use trusted meta-data to compute a set of admissible formats, and
> if the set has multiple members, use probing to pick one of them.
>
> Example: foo.qcow2 -> { qcow2 }, no probing
>
> Example: foo.qcow -> { qcow, qcow2 }, probe to pick one
>
> Likewise for foo.vhdx and foo.vhd.
>
> To ensure this actually knocks out condition (b), all members of the set
> must have the image contents used by their members' probes within their
> trust boundary.
>
> Example: { qcow, qcow2 } is fine, because both formats have a header,
> and each header covers the bytes either probe examines.
>
> Example: { raw } is fine, because there is no probing.
>
> Counterexample: { raw, qcow2 } is not possible, because qcow2 probes
> outside raw's trusted metadata.
>
> Note my careful wording "contents used by [other] probes".  Right now we
> simply assume that the first 2048 bytes can be trusted.  This is not
> obviously the case!  If I remember correctly, you proposed to cut it to
> 512 bytes, which feels a lot safer, since any sane format probably
> aligns (untrusted) image contents to at least a 512 byte boundary, but
> is still theoretically unsound.
>
> PRO and CON like my proposal to guess from trusted meta-data only.  The
> difference is in what existing usage exactly it breaks.
>
> Can be combined with "refuse to use a format without an explicit format=
> when any other non-raw format probe accepts", just like everything else
> proposed so far.

Can also be mitigated: lengthy transition period where we warn "this
usage is insecure, and we'll eventually break it; here's a hint on
secure usage".

[...]



reply via email to

[Prev in Thread] Current Thread [Next in Thread]