CVE-2016-3066: Infoleak

First published: Tue Mar 22 2016(Updated: )

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

Credit: secalert@redhat.com

Never miss a vulnerability like this again

Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.

Read MoreStart Free Trial

• collector/nvd-index
• agent/type
• agent/softwarecombine
• agent/first-publish-date
• collector/mitre-cve
• source/MITRE
• agent/weakness
• agent/last-modified-date
• agent/references
• agent/author
• agent/severity
• agent/description
• agent/event
• collector/redhat-bugzilla
• source/Red Hat
• alias/CVE-2016-3066
• agent/tags
• agent/trending
• vendor/spice-gtk project
• canonical/spice-gtk project spice-gtk
• version/spice-gtk project spice-gtk/0.1.0
• version/spice-gtk project spice-gtk/0.2
• version/spice-gtk project spice-gtk/0.3
• version/spice-gtk project spice-gtk/0.4
• version/spice-gtk project spice-gtk/0.5
• version/spice-gtk project spice-gtk/0.6
• version/spice-gtk project spice-gtk/0.7
• version/spice-gtk project spice-gtk/0.8
• version/spice-gtk project spice-gtk/0.9
• version/spice-gtk project spice-gtk/0.10
• version/spice-gtk project spice-gtk/0.11
• version/spice-gtk project spice-gtk/0.12
• version/spice-gtk project spice-gtk/0.12.101
• version/spice-gtk project spice-gtk/0.13
• version/spice-gtk project spice-gtk/0.13.17
• version/spice-gtk project spice-gtk/0.13.29
• version/spice-gtk project spice-gtk/0.14
• version/spice-gtk project spice-gtk/0.15
• version/spice-gtk project spice-gtk/0.15.3
• version/spice-gtk project spice-gtk/0.16
• version/spice-gtk project spice-gtk/0.17
• version/spice-gtk project spice-gtk/0.18
• version/spice-gtk project spice-gtk/0.19
• version/spice-gtk project spice-gtk/0.20
• version/spice-gtk project spice-gtk/0.21
• version/spice-gtk project spice-gtk/0.22
• version/spice-gtk project spice-gtk/0.23
• version/spice-gtk project spice-gtk/0.24
• version/spice-gtk project spice-gtk/0.25
• version/spice-gtk project spice-gtk/0.26
• version/spice-gtk project spice-gtk/0.27
• version/spice-gtk project spice-gtk/0.28
• version/spice-gtk project spice-gtk/0.29
• version/spice-gtk project spice-gtk/0.30
• version/spice-gtk project spice-gtk/0.31
• version/spice-gtk project spice-gtk/0.32
• version/spice-gtk project spice-gtk/0.33