Bug 1320263 (CVE-2016-3066) - CVE-2016-3066 spice-gtk: hijacks clipboard and sends contents to remote servers
Summary: CVE-2016-3066 spice-gtk: hijacks clipboard and sends contents to remote servers
Alias: CVE-2016-3066
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Whiteboard: impact=low,public=20160322,reported=2...
Depends On: 1320264 1320265
Blocks: 1320267
TreeView+ depends on / blocked
Reported: 2016-03-22 17:06 UTC by Kurt Seifried
Modified: 2019-06-08 21:05 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2018-03-20 14:37:57 UTC

Attachments (Terms of Use)

Description Kurt Seifried 2016-03-22 17:06:16 UTC
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.


Comment 1 Kurt Seifried 2016-03-22 17:06:32 UTC

Name: Daniel P. Berrange (Red Hat)

Comment 2 Kurt Seifried 2016-03-22 17:07:42 UTC
Created spice-gtk tracking bugs for this issue:

Affects: fedora-all [bug 1320265]

Comment 3 Kurt Seifried 2016-03-22 17:07:52 UTC
Created mingw-spice-gtk tracking bugs for this issue:

Affects: fedora-all [bug 1320264]

Comment 4 Hans de Goede 2016-03-22 18:41:24 UTC
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.

Comment 5 bancfc 2016-03-30 04:48:16 UTC
This can be tackled by implementing a "secure clipboard" scheme as proposed here some time ago:


Comment 6 Ivan Kozik 2017-12-23 07:49:22 UTC
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.

Comment 7 Stefan Cornelius 2018-03-20 14:38:14 UTC

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/.

Note You need to log in before you can comment on or make changes to this bug.