Secure Your KVM Virtual Machines

Jailbreak: Guard Against Breakouts on Your Virtual Machines


It is dangerous simply to pass host devices through to the virtual machine. If you mount a filesystem on the virtual machine that other computers on the LAN can also see, the infected guest could use this pass-through to distribute malicious programs, change configuration files, or destroy existing documents. The valuable project files on the NAS would then be goners. Administrators should therefore carefully consider what filesystems depend on which virtual machine. Ideally, the virtual machine uses only its own image files.

Selected USB devices – and even a complete USB port – can pass through to the virtual machine (Figure 3). In the following example, all devices end up at port 1.1 on bus 2 of the virtual machine:

qemu-kvm -usb -device usb-host,hostbus=2,hostport=1.1 ...
Figure 3: Hot plugging USB hardware also works on virtual machines: A USB stick was plugged in and unplugged on this Fedora host. This practice is especially dangerous if Windows is running as a guest and media startup is allowed.

However, the risk of someone plugging an infected USB flash drive into the host computer and then smuggling malicious software onto the virtual machine must also be considered. The same concerns apply to DVD drives  – which can even boot a Live system under certain circumstances.

Hidden Control Center

If the virtual machine is allowed to write its screen output to a window, pressing Ctrl+Alt+2 changes to the monitor (Figure 4). Once there, you can restart the system or change to the virtual DVD, among other things. If the virtual machine is running on a server with no graphics output, the monitor can also be redirected. The following command serves up the console available via a TCP connection on port 4444:

qemu-kvm -monitor tcp::4444,server,nowait ...
Figure 4: The administrator can serve up the monitor …

All communication is unencrypted here (Figure 5). Consequently, anyone could use Telnet to dock with the virtual machine and make desired changes. Admins should therefore at least restrict access to one computer, for example, the computer with the IP address of

qemu-kvm -monitor tcp:,server,nowait ...
Figure 5: … to everyone on the network.

Ideally, however, you would want to prevent this kind of access and instead use the libvirt tools – in particular, virsh. The latter lets you call monitor commands directly via:


By default, each newly created virtual machine is given a serial port, which administrators can use to connect via virsh console.

You can even redirect the console, like the monitor, for example, to the physical serial port on the host or via TCP [4]. The (boot) messages seen on this console depend on the guest. Depending on the configuration, the administrator could even use this method to log in. Although this approach is useful for remote maintenance of a screenless virtual machine, again all communication is unencrypted. You should not redirect the output from the host system to the serial interface, but use a secure method such as SSH instead.


By default, Qemu writes the screen output from the virtual machine to a window on the host desktop. Alternatively, you can enable a built-in Qemu VNC server. The desktop on the virtual machine then displays a VNC client. By default, this VNC client must run on the same computer as the virtual machine; Qemu only allows connections from the local host IP address However, admins can change the default using the -vnc parameter:

qemu-kvm -vnc :1 ...

With this setting, which is mentioned by many guides, anyone could connect to the VNC server. If the host computer has an IP address of, the following command displays the screen from the first virtual machine on the administrator's desktop (Figure 6):

Figure 6: VNC lets you control a virtual machine from a remote host; any VNC client will do.

If you forgot to log out of the guest system, the attacker is now gifted with the system. For the same reason, you should not simply share the VNC server by using virt-install with the -graphics parameter, even if this facilitates remote installation. The TCP ports are known, and KVM uses numbers from 5900 upward by default (the port is calculated as the number 5900 plus the display number).

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Virsh Libvert Tool

    With the command-line tool virsh, a part of the libvirt library, you can query virtual machines to discover their state of health, launch or shut down virtual machines, and perform other tasks – all of which can be conveniently scripted.

  • Controlling virtual machines with VNC and Spice
    Administrators on Linux virtual machines tend to use VNC to transfer the graphical system to Virtual Machine Manager or a VNC client. One alternative is Spice: If the guest system is running the QXL driver, you can look forward to fast graphics and audio pass through.
  • Live snapshots with Virtual Machine Manager
    In the scope of developing Fedora 20, the live snapshot function, which has long been supported by libvirt, was integrated with the graphical front end. If you prefer to avoid command-line acrobatics à la Virsh, you can now freeze your virtual KVM and Xen machines in VMM at the press of a button.
  • Avoiding KVM configuration errors
    Virtualization solutions isolate their VM systems far more effectively than a container host isolates its guests. However, implementation weaknesses in the hypervisor and configuration errors can lead to residual risk, as we show, using KVM as an example.
  • Using Libvirt with Python to manage virtual machines
    If you do not want to use any of the major management frameworks to manage your virtual machines, the Libvirt library for Python provides an alternative.
comments powered by Disqus