Jailbreak: Guard Against Breakouts on Your Virtual Machines

Smugglers

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 192.168.100.21:

qemu-kvm -monitor tcp:192.168.100.21:4444,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:

qemu-monitor-command

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.

Figurative

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 127.0.0.1. 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 192.168.100.21, the following command displays the screen from the first virtual machine on the administrator's desktop (Figure 6):

vncviewer 192.168.100.21:5901

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).