On Thu, Feb 20, 2014 at 02:02:03PM +0400, Michael Tokarev wrote:
> > But I don't understand what is meant by the second part:
> >
> > | * Saving/Loading state to/from file.
> > | For example:
> > | https://bugzilla.redhat.com/show_bug.cgi?id=588133#c8
> > | https://bugzilla.redhat.com/show_bug.cgi?id=588133#c9
> >
> > The RH bugs are restricted and I don't understand what is meant with
> > "saving/loading state to/from file". Is this about snapshots or
> > malformed images? Do you have an idea?
>
> It is like snapshots, yes. One can save a guest memory image into
> a file and load it later. It is pretty much like migration (and
> implemented using the same mechanism), but with a delay between
> saving and loading.
>
> One of the bugs mentioned above is about giving developer such a
> saved file from local qemu asking for help in diagnosing an apparent
> bug, and that image will try to exploit developer's qemu by using
> one of these flaws. Something like that anyway -- see
> http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00612.html
>
> Another possible scenario is someone distributing virtual machines
> for end-users, trying to exploit their qemu.
>
> Unlike for, say, gif images or word documents or whatever, qemu
> guest image _may_ come in one of 2 forms: it is just the drive
> image (content of virtual hard drive), which you run and it boots
> from the beginning as your regular PC will do. Or this drive
> image coupled with memory image, so when you run it, your system
> is in some non-initial runtime state. It is definitely unusual
> to distribute something in the second form, together with the
> memory state.
>
> So I can imagine someone selling pre-loaded virtual machines
> (doing it this way, together with memory state, is rare but can
> have its reasons too, say, for a system which require significant
> boot time). Or, for example, your qemu/kvm hosting provider can
> have a function to transfer whole your virtual machine (together
> with the memory state) to you - either in terms of files like
> that, or using online migration.
>
> When you perform save/load locally in your usual environment where
> you run qemu, you don't let stranger to modify the memory state
> files created by qemu. So locally this is not exploitable (unless
> you use already hacked/modified qemu to create the images in the
> first place, but that's obviously not very interesting case).
>
> >> So.. oh well. I'd really love to not backport all this shit to
> >> wheezy... ;)
> >
> > If "Saving/Loading state to/from file" is negligable as well,
> > I would mark it as a non-issue in the tracker.
>
> Both ways to "use" one of these vulns are real, but both are quite
> difficult to use, hence the probably-low-impact.
>
> Basically we've two possible ways to use these vulns.
>
> First is to "spread" a break-in to other machines by, after breaking
> into one machine (using some other way) and hacking qemu on it, it
> becomes possible to break into qemu on the receiving-migration machine.
>
> And second is when someone gives whole guest image (together with the
> memory state) to you, tricking you to run it one way or another.
>
> That's what issues are all about. Not very serious, but not a non-issue
> either.
Thanks for the verbose explanation. Since both attacks as rather far-fetched,
I'll mark these as <no-dsa> in the security tracker. So we don't need a
Wheezy backport through security.debian.org
Cheers,
Moritz
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
