Breaking Confidential VMs: Exploiting ACPI Machine Language for Root Access

TLDR: Researchers at Black Hat 2024 demonstrated that Confidential Virtual Machines (CVMs) are vulnerable to ACPI Machine Language (AML) injection attacks. By exploiting the runtime interface between the host and guest firmware, an attacker can inject malicious code that executes during system startup, bypassing standard attestation protections. This research proves that even in hardened cloud environments, the trust boundary between host and guest remains a critical, often overlooked, attack surface.

Confidential computing is the industry’s current answer to the "trust the cloud provider" problem. By using hardware-based memory encryption and attestation, CVMs promise that even a malicious hypervisor or a rogue cloud administrator cannot inspect or tamper with your data in memory. It sounds perfect on paper, but as we’ve seen time and again, security is only as strong as the weakest interface. The research presented at Black Hat 2024 on AML injection attacks proves that the runtime communication channel between the host and the guest is a massive, gaping hole in the current CVM threat model.

The Mechanics of the AML Injection

At the heart of this attack is the ACPI Machine Language (AML), a bytecode language used by the firmware to manage hardware configuration and power states. When a system boots, the OS kernel loads and interprets this AML code. In a traditional VM, this is standard operating procedure. In a CVM, however, the host is supposed to be untrusted. The problem is that the host is still responsible for providing the ACPI tables to the guest.

The researchers identified that the runtime interface used to pass these tables—specifically the QEMU firmware configuration device—is not adequately protected against malicious modification after the initial boot. By injecting custom, malicious AML code into this interface, an attacker can force the guest kernel to execute arbitrary instructions during the boot process. Because this code runs before the guest OS has fully initialized its own security controls, it effectively grants the attacker a foothold before the system is even "live."

From Bytecode to Root Shell

The demo provided by the researchers is a masterclass in privilege escalation. By modifying the AML bytecode, they were able to manipulate the guest’s initial RAM disk (initrd) script. In the Linux case study, they demonstrated how to inject a command that opens a root shell on a virtual serial port.

For a pentester, this is a goldmine. If you are assessing a cloud environment that relies on CVMs, you aren't just looking for application-layer bugs anymore. You are looking at the firmware-to-guest communication channel. If you can influence the configuration data passed from the host to the guest, you aren't just breaking the VM; you are breaking the entire premise of confidential computing.

The researchers specifically highlighted CVE-2024-3012, which underscores the severity of these firmware-level vulnerabilities. The fix, as recommended by AMD, involves moving toward a "measured boot" process using a virtual Trusted Platform Module (vTPM). You can find the relevant technical details in the AMD security advisory.

Why This Matters for Your Next Engagement

If you are a researcher or a pentester, stop assuming that "Confidential" means "Invulnerable." The industry is currently in a transition phase where the hardware supports these features, but the software stacks—specifically the firmware and the host-guest interfaces—are still catching up.

During an engagement, look for how the CVM is provisioned. Is the boot process measured? Are you able to inspect the ACPI tables being passed to the guest? If the environment doesn't enforce strict vTPM-based attestation for every component of the boot chain, you have a potential path for code injection. The tools used in this research, such as QEMU and OVMF, are standard, but the way they are configured in a CVM context is where the vulnerability lies.

The Defensive Reality

Defending against this requires a shift in how we view the cloud stack. Blue teams need to ensure that their CVM deployments are not just using memory encryption, but are also strictly enforcing measured boot. If your attestation report doesn't include the ACPI tables, you are effectively blind to this class of attack.

Cloud providers are starting to open-source their components, such as Microsoft’s OpenHCL, which is a step in the right direction for transparency. However, transparency is not a substitute for a secure architecture. Until the industry moves to a model where every single byte of configuration data passed to a guest is cryptographically signed and verified by the guest itself, these injection vectors will persist.

The next time you are auditing a cloud infrastructure, don't just look at the web apps. Look at the boot logs. Look at the attestation reports. If you see a gap between what the host provides and what the guest verifies, you’ve found your entry point. The era of blind trust in CVMs is over; it’s time to start treating the host-guest interface with the same level of scrutiny we apply to any other untrusted input.