Bug#739589: qemu: Multiple security issues
Adding more issues to the same bugreport. CVE-2014-3461 http://article.gmane.org/gmane.comp.emulators.qemu/272322 Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739589: qemu: Multiple security issues
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 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
Bug#739589: qemu: Multiple security issues
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 - i
Bug#739589: qemu: Multiple security issues
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. 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? > 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. > 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. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739589: qemu: Multiple security issues
20.02.2014 12:24, Moritz Muehlenhoff wrote: > Package: qemu > Severity: grave > Tags: security > > 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. In particular, this conclusion: Considering the preconditions, I think that the impact on typical qemu usage is low. Still, I think these patches make sense for qemu-stable. So it has even been questioned whenever those fixes are good for the next qemu stable release or not. 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). So.. oh well. I'd really love to not backport all this shit to wheezy... ;) Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739589: qemu: Multiple security issues
Package: qemu Severity: grave Tags: security Hi, multiple security issues were reported in qemu/KVM: CVE-2013-4148 http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00395.html CVE-2013-4149 http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00396.html CVE-2013-4150 http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00397.html CVE-2013-4151 http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00425.html CVE-2013-4526 http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00398.html CVE-2013-4527 http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00399.html CVE-2013-4529 http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00400.html CVE-2013-4530 http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00401.html CVE-2013-4531 http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00402.html CVE-2013-4532 http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00403.html http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00414.html http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00404.html CVE-2013-4533 http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00407.html CVE-2013-4534 http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00406.html CVE-2013-4535 http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00408.html CVE-2013-4536 http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00408.html CVE-2013-4537 http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00409.html CVE-2013-4538 http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00410.html CVE-2013-4539 http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00411.html CVE-2013-4540 http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00412.html CVE-2013-4541 http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00413.html CVE-2013-4542 http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00416.html CVE-2013-6399 http://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00405.html Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
