Daniel P. Berrange of Red Hat reports: The spice-gtk widget (used in virt-viewer, remote-viewer, virt-manager and GNOME boxes applications) has a feature whereby it will automatically synchronize the local desktop client clipboard with the remote guest OS clipboard. The aforementioned applications all enable this feature unconditionally AFAICT. [virt-manager]$ git grep auto-clipboard virtManager/viewers.py: gtk_session.set_property("auto-clipboard", True) [gnome-boxes]$ git grep auto-clipboard src/spice-display.vala: BoxConfig.SyncProperty () { name = "auto-clipboard", default_value = true }, src/spice-display.vala: gtk_session.bind_property ("auto-clipboard", toggle, "active", [virt-viewer]$ git grep auto-clipboard src/virt-viewer-session-spice.c: g_object_set(self->priv->gtk_session, "auto-clipboard", TRUE, NULL); The way this works is that as soon as data in the local client clipboard is updated, it is immediately transfered to the remote guest OS clipboard. This happens *regardless* of whether the remote desktop window actually has keyboard focus or not. The only requirement is that the guest OS has the spice guest agent enabled in the QEMU config, and running in the guest. This is done by default for any recent RHEL or Fedora install, and is an option for Windows guests too, so exposure is potentially quite broad. Now consider you have one or more SPICE sessions open to some guest OS' on your local desktop. Now you switch to firefox to use some website that requires login. You are sensible so you use a program like KeepPassX to manage passwords for all your websites. You use KeepPassX to copy the password for the website into the clipboard, then switch to firefox and paste the password into firefox. At no time have you interacted with the SPICE sessions for the guest OS you have open. Regardless though, your password has been sent to every single guest OS, without any indication to the user that this has happened. This is contrary to normal clipboard behaviour, where you need to give an explicit action (eg Ctrl-V, or Menu -> Edit -> Paste) in order to give the application your clipboard data. As such I think users will not be expecting this data leakge to guests. Consider for example, you are a cloud administrator and have a virt-viewer session open to one of your customers' virtual machines. Meanwile you use keepassx and firefox to access your customer billing admin interface. The password for your billing web interface has just been given away to any application running in your customer's VM. Opps. How to address this is tricky, because at the same time as causing this horrific data leakage, the auto-clipboard feature is incredibly useful and convenient for desktop virt when you /do/ trust the guest OS you are working with. At a very minimum, I think that the clipboard data should *only* ever be transferred to the remote guest OS, if the SPICE GTK widget actually has keyboard focus. This would immediately remove the majority of the data leakage risk, but that's probably not sufficient for many scenarios. So as a second step, I think all applications using spice-gtk *must* provide a way to turn off the automatic clipboard synchronization feature. Personally I'd make auto-clipboard sync an opt-in feature which you must explicitly enable, not enabled out of the box. Possibly we should consider warning the user about the data leakage risk inherant in this. NB, this issue is public knowledge, because it was raised by a user on the #virt IRC channel on irc.oftc.net. They were concerned about precisely the scenario listed here - they did not want their passwords leaked to their guest OS sessions. Regards, Daniel
Acknowledgments: Name: Daniel P. Berrange (Red Hat)
Created spice-gtk tracking bugs for this issue: Affects: fedora-all [bug 1320265]
Created mingw-spice-gtk tracking bugs for this issue: Affects: fedora-all [bug 1320264]
The original description of this bug is not entirely accurate. Under normal use, at least with a Linux guest, the spice-gtk widget will only tell the guest that there is clipboard data, and in which formats / mime-types this data is available, it will not request the data from the clipboard, nor send it, without the guest requesting the data (in a specific format). Now a malicious guest could request this data immediately so there definitely is something to be concerned here about. But normally the guest will not request it (unless perhaps it is say running a clipboard manager?). So in theory the guest should only request the actual clipboard contents on CTRL+v (or a paste menu click), which can only happen when the spice-gtk widget has focus, so things can potentially be improved by not allowing the guest to request the clipboard contents when spice-gtk does not have focus. Such a fix may need to be configurable since this may very well break e.g. clipboard managers in the guest. Note that this can not only be turned off client-side as noticed in the original description, but in case people are worried about a leak the other direction, it can also be disabled server (host) side for a specific vm.
This can be tackled by implementing a "secure clipboard" scheme as proposed here some time ago: https://lists.freedesktop.org/archives/spice-devel/2015-April/019617.html
This is very bad, especially because clipboard sharing is unconditionally enabled with no warning. It's easy to think that guests can't read the host clipboard because one never enabled it (where?), or because spice-vdagent isn't installed (yet... until the guest is compromised). VMware Workstation doesn't allow guests to see new host clipboard data until the guest window is focused, which may be a good compromise that doesn't require learning secure-clipboard shortcuts. It also forbids a guest->host clipboard change unless the guest window is focused.
Statement: Red Hat Product Security has rated this issue as having Low security impact. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.