| Reported on: | 20150814 |
|---|---|
| Published on: | 20150903 |
| Fixed on: | 20150903 |
| Reported by: | Han Han |
|---|---|
| Patched by: | John Ferlan |
The virStorageVolCreateXML API had a bug where it could create a volume on a root-squash NFS mount, but then fail to remove that volume if later steps during the API encountered problems. This was further compounded by code which used a wrong conditional on whether the new volume needed to have permissions changed, making it more likely to trigger the failed unlink attempt. Poor error handling after a failed unlink left libvirt with an inconsistent view of the storage volume that could then result in a libvirtd crash. While the libvirtd crash might be delayed until by subsequent actions from a read-only connection, the conditions that set up the crash can only be triggered by a client with a read-write connection.
When using fine-grained Access Control Lists (ACL), the virStorageVolCreateXML API only requires the storage_vol:create permission. A client with this privilege but lacking the more-powerful domain:write permission could exploit the API bugs to cause a denial-of-service attack by taking down libvirtd through a crash. It can also be argued that the ability to cause libvirt to create files which it cannot delete can be used as a denial-of-service attack on storage resources.
The problems with libvirt creating a file which it does not then clean up on error is specific to root-squash NFS, so one mitigation is avoiding the use of the root-squash option when exporting NFS volumes for use by libvirt storage pools. Note that in general, the use of root-squash NFS does not add any real security (it makes certain tasks harder for a root user, but the root user can trivially change ids to another user to still perform those tasks). Furthermore, it is possible to prevent the denial of service attacks by stopping the use of the fine grained access control mechanism (while this does not prevent a crash, such a crash is no longer a security problem as there is no longer a privilege boundary between a user creating a volume and a user with full system access).