| Reported on: | 20141031 |
|---|---|
| Published on: | 20141105 |
| Fixed on: | 20141106 |
| Reported by: | Eric Blake |
|---|---|
| Patched by: | Eric Blake |
At the time the VIR_DOMAIN_XML_MIGRATABLE flag was added to the virDomainGetXMLDesc API, the qemu implementation chose to make the flag always imply the VIR_DOMAIN_XML_SECURE flag. The secure flag had been previously deemed unsafe to use from a read-only connection; however, because the new migratable flag is not restricted against use by read-only clients, a client can use the new flag to bypass the restrictions placed on the use of the old flag.
A read-only client can trigger an information leak of data that should normally require the use of VIR_DOMAIN_XML_SECURE to access. Fortunately, the only data in this category is the value of an optional VNC password.
VNC passwords are notoriously weak (they are capped at an 8 byte maximum length; the VNC protocol sends them in plaintext over the network; and FIPS mode execution prohibits the use of a VNC password), so it is recommended that users not create domains with a VNC password in the first place. Domains that do not use VNC passwords do not suffer from information leaks; the use of SPICE connections is recommended not only because it avoids the leak, but also because SPICE provides better features than VNC for a guest graphics device. It is also possible to prevent the leak by denying access to read-only clients; for builds of libvirt that support fine-grained ACLs, this course of action requires ensuring that no user is granted the 'read' ACL privilege without also having the 'read_secure' privilege.