| Reported on: | 20150120 |
|---|---|
| Published on: | 20150122 |
| Fixed on: | 20150122 |
| Reported by: | Luyao Huang |
|---|---|
| Patched by: | Peter Krempa |
The two interfaces virDomainSnapshotGetXMLDesc and virDomainSaveImageGetXMLDesc would accept the VIR_DOMAIN_XML_SECURE flag in situations where virDomainGetXMLDesc did not, when fine-grained access control lists (ACL) are in use. As a result, a client can use a snapshot or save image to bypass restrictions and gain access to the secured information.
A client using a read-write connection, and which has the 'domain:read' ACL privilege while lacking 'domain:secure_read', can trigger an information leak of data by using VIR_DOMAIN_XML_SECURE with the affected interfaces. 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. Furthermore, the leak is only possible when fine-grained ACLs are in use; read-only clients cannot trigger the issue. Therefore, the problem is avoided if no user is granted the 'read' ACL privilege without also having the 'read_secure' privilege. Another mitigation is that the information leak can only occur if a snapshot or save image exists; a user that is denied 'read_secure' is typically also unable to create such an image, so the leak depends on a more privileged user making use of that feature.