Older versions of libvirt (version 1002008 or order) or builds without dhcp leases feature compiled it are vulnerable to shell escape through for-libvirt. An attacker can execute arbitrary shell code either locally or remotely over ssh.
Luckily, most linux distributions these days have the dhcp leases feature compiled in and libvirt library in version that prevents from the affected code being executed.
This bug still deserves a fix if there's someone running an old hypervisor or calling those methods explicitly via send.
The following code prints "test" string into system log/journal by crafting a domain name to escape the shell:
require "fog/libvirt"
compute = Fog::Compute.new(provider: :libvirt, libvirt_uri: "qemu:///system")
server = compute.servers.create(name: "test; logger test")
# Use this call to trigger the bug on systems with
# recent version of libvirt:
server.send(:addresses_ip_command)
The proposed fix is very simple so it could be backported if you choose to do so. I suggest to drop the code in question completely from the future versions of fog-libvirt.
Red Hat Security Response Team was made aware of this bug, no products are known to be affected, no CVE was filed.
Older versions of libvirt (version 1002008 or order) or builds without dhcp leases feature compiled it are vulnerable to shell escape through for-libvirt. An attacker can execute arbitrary shell code either locally or remotely over ssh.
Luckily, most linux distributions these days have the dhcp leases feature compiled in and libvirt library in version that prevents from the affected code being executed.
This bug still deserves a fix if there's someone running an old hypervisor or calling those methods explicitly via send.
The following code prints "test" string into system log/journal by crafting a domain name to escape the shell:
The proposed fix is very simple so it could be backported if you choose to do so. I suggest to drop the code in question completely from the future versions of fog-libvirt.
Red Hat Security Response Team was made aware of this bug, no products are known to be affected, no CVE was filed.