20.02.2014 13:09, Moritz Muehlenhoff wrote: > Hi Michael, > > On Thu, Feb 20, 2014 at 12:55:31PM +0400, Michael Tokarev wrote: >>> Hi, >>> multiple security issues were reported in qemu/KVM: >> [...] >> >> These are all about the same thing, with references to 23 patches >> from the same thread starting there: >> >> http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00394.html >> >> It is about state loading issues, which is about migration between >> two (hopefully) qemu instances or guest save/load functionality. >> The first message in the series explains conditions when this can >> happen. > > I had missed the initial mail from the thread, that explains it well > enough. I agree that the attack scenario during migration between > nodes is negligable and a non-issue.
It isn't exactly a non-issue really, or else it'd not be necessary to assign (multiple) CVE IDs. Even with migration scenario there are possibilities to exploit these by using one of these vulnerabilities together with some other vulnerability (and this is mentioned in the first email in that thread). Impact is quite low still. > 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. >> But now I'm not really sure what to do with this bugreport. It >> is a good amount of work, especially to backport those to wheezy >> (since code changed significantly since that), with quite low >> outcome (because the whole thing does not seem very important, >> even for qemu developers - note that this patchset hasn't been >> applied still, which might be due to another issue in qemu >> community). > > Feel free to downgrade to non-RC severity until the patches > are merged in 1.8. Note that, while many people has been involved in code audit and patching, the series received quite good criticism from Peter Maydell who offerent alternative ways to fix some of the issues or questioned validity of the proposed fixes, with not much discussion following. I'll ping this thread again - it's not nice when such a large and good work is being thrown away. BTW, next version of qemu will most likely be 2.0. Without any good reason for that :) Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
