In late 2022, security researchers uncovered a subtle but impactful issue in two important OpenStack component packages: Sushy-Tools (up to version .21.) and VirtualBMC (up to version 2.2.2). This issue, tracked as CVE-2022-44020, arises when changing a virtual machine’s boot device—an operation that might seem routine.

Surprisingly, this change can quietly strip away VNC or serial port password protection from the underlying libvirt XML domain. While this doesn't affect out-of-the-box configurations, it can bite if you use these tools in a "production-like" (but still "unsupported") environment. Below, I’ll break down exactly what happens, how it’s exploitable, and what you can do about it.

What’s Going On?

When you use Sushy-Tools or VirtualBMC to manage VMs, these tools often interact with libvirt, which maintains each VM as an XML configuration file. Sometimes, admins add password protection to the VNC or serial interfaces in these XML files—preventing unauthorized access to the VM’s consoles.

The problem is: If you change the boot device (using REST APIs, Redfish, etc.), these tools rewrite (or "apply changes" to) those same libvirt XML domain files. But they don't preserve the password configuration. Any custom password you previously set gets stripped away, unintentionally allowing anyone who can connect to the console unrestricted access.

You change the boot device using these tools.

Result: Password protection on the console is removed without warning.

Simple Exploit Example

Suppose you have a demo-vm with a password-protected VNC console. At first, the libvirt XML could look something like:

<graphics type='vnc' port='-1' autoport='yes' listen='...' passwd='SuperSecretPass'/>

By *default*, connecting with virt-viewer or similar tools will require a password.

Now, say Sushy-Tools is used to change the boot device to PXE. The tool internally rewrites the XML file (not fully merging old and new settings).

What the XML may look like after

<graphics type='vnc' port='-1' autoport='yes' listen='...'/>

The passwd attribute is gone! Anyone who discovers the console port can view and interact with the VM without any password.

curl -X PATCH \

-H 'Content-Type: application/json' \

d '{"Boot": {"BootSourceOverrideTarget": "Pxe"}}' \

http://localhost:800/redfish/v1/Systems/demo-vm

Why Did This Happen?

The tools overwrite the whole <graphics> section instead of safely merging settings. This loses any custom attributes (like passwd).

Should You Worry?

- If you use Sushy-Tools/VirtualBMC just for testing or demo, and never set VNC passwords, you can relax.
- If you added passwords for remote console security and use these tools to update boot settings, you have a gap.
- This is not an issue in standard production OpenStack deployments—just certain "DIY production-like" or advanced development setups where these tools stand in for full BMCs.

Update Sushy-Tools to v.22.+ and VirtualBMC to v2.2.3+.

Sushy-Tools Release Notes
 
 VirtualBMC Commit Fix

- Alternatively, recheck your VM XML files after using these tools and re-add password protection if needed.

References

- NIST NVD: CVE-2022-44020
- OpenStack Sushy-Tools GitHub Issue
- OpenStack VirtualBMC Security Advisory
- Sushy-Tools on GitHub
- VirtualBMC on GitHub

Final Thoughts

CVE-2022-44020 is a keen reminder that management tools can unintentionally break your security posture when changing VM settings. Always monitor your configurations after using such tools and keep your components up to date. If in doubt, review the XML!

Timeline

Published on: 10/30/2022 00:15:00 UTC
Last modified on: 02/09/2023 01:33:00 UTC