Title here
Summary here
How Does It Work?
AMD SEV-SNP and Intel TDX enable Confidential VMs (CVMs). With these CVMs, the untrusted hypervisor is still responsible for resource and configuration management. Consequently, the hypervisor also manages interrupts for CVMs. In Heckler, the hypervisor uses malicious interrupts to compromise the security of the CVMs. Our insight is to use the interrupt handlers that have global effects, such that we can manipulate a CVM’s register states to change the data and control flow. Let’s first look at how interrupts are handled during a benign execution. The hypervisor hooks on physical interrupts from the interrupt controller and sends them to the CVMs. The CVMs service these interrupts by executing handlers. In the x86 architecture, hardware exceptions (e.g., divide-by-zero, undefined instruction) are also mapped to interrupt numbers. For a detailed explanation check out our blog post.
Int 0x80
In the x86 architecture, user-space applications execute legacy 32-bit system
calls using the int 0x80 instruction. When the hardware executes this
instruction, it raises interrupt number 128 (0x80) which invokes the 32-bit
system call handler in the Linux kernel. This system call handler has a global
effect—it returns the result of the system call in rax. We use this global
effect in the handler to compromise the CVMs execution. Specifically, a
malicious hypervisor injects int 0x80 to induce a change in the value of rax
that a victim application uses. For example, change rax right before an
application checks it to successfully authenticate a user. This allows the
malicious hypervisor to bypass authentication checks (e.g., OpenSSH, sudo).
Signals
The OS converts different hardware exceptions to signals that are delivered to user-space applications. The applications register signal handlers which can have global effects. In AMD SEV-SNP, the hardware exceptions are mapped to interrupt numbers that a malicious hypervisor can inject. These malicious interrupts trick the OS into sending a signal to the user-space application. Depending on the effects application’s signal handler, this malicious interrupt injection can be used to compromise the security of the CVM.
In the Animation below, the function updates the mean of a data set when new data is added to it. Crucially, in a signal handler, the application discards any faulty data (e.g., data that overflows the mean) and reverts the mean. An attacker can bias this data set by using Heckler.
Breaking into CVMs with Heckler
OpenSSH
Using Heckler, we attack OpenSSH v9.4.P1+ to compromise its authentication and
get a shell on the CVM. Without Heckler, the attacker is not authorized to get a
shell.
Specifically, OpenSSH calls mm_answer_authpassword to decide if authentication
is successful. We use Heckler’s int 0x80 attack and inject an interrupt when
this function executes to change its return value. To determine when to inject
the interrupt, we use the hypervisor’s ability to observe page faults.
mm_answer_authpassword invokes auth_password on a different page. We inject
int 0x80 when we observe that execution returns back to the
mm_answer_authpassword to compromise its return value.
Sudo
We demonstrate an attack on the sudo binary in the Ubuntu 23.10 distribution to get a root shell on the CVM. Specifically, an attacker with a non-root shell on the CVM can escalate privilege to a root shell using Heckler.
Like the OpenSSH attack, we identify functions that lie on different pages. We observe the page trace in the hypervisor and use int 0x80 to compromise the return values leading to successful authentication.
In summary, a malicious hypervisor can use Heckler to gain access to a shell (using the OpenSSH attack) on the CVM and escalate privilege to a root shell (using the sudo attack). Further, Heckler can be used to compromise victim applications by sending arbitrary signals. For more details, please see our paper and our code.
Affected Hardware and Software
All Intel TDX and AMD SEV-SNP processors are vulnerable to Heckler. See our FAQs for more information.
FAQ
Q: Does this attack apply to other versions of SEV (e.g., SEV-ES)?
- While we haven’t tested this, in theory, yes all older versions of SEV are vulnerable to Heckler.
Q: Does the int 0x80 attack only work on 32-bit binaries?
- No.
int 0x80is used to invoke legacy 32-bit system calls. This instruction is also valid in 64-bit binaries. Furthermore, Heckler does not require the application to explicitly execute theint 0x80instruction. Therefore, all application binaries are vulnerable to Heckler if they execute with a Linux kernel that registers a vulnerableint 0x80handler.
Q: Does Heckler affect non-confidential VMs that I have in the cloud?
- No. Heckler assumes a malicious hypervisor to inject interrupts. For normal cloud VMs, the hypervisor is implicitly trusted and will not attack the VMs. Also, co-tenant VMs cannot use Heckler because the hypervisor detects and filters any malicious interrupt injections from other VMs.
Q: How do I protect myself from Heckler?
Heckler is tracked under 2 CVEs: CVE-2024-25744 and CVE-2024-25743
For Intel TDX, there are patches to the Linux kernel that check if
int 0x80is externally injected. TDX is not vulnerable to the attack from signals as the hardware blocks external injection of interrupts between 0-30.For AMD SEV-SNP, turn off x86 emulation in the Linux kernel which will prevent Heckler from using the effects of the
int 0x80handler. Currently, there is no fix to protect against Heckler’s signal attacks.For robust defense, we recommend that cloud users switch to protected interrupt delivery available on AMD SEV-SNP. Unfortunately, as of 4th April 2024, there is no software support to use this hardware feature in neither mainline Linux nor AMD prototype.
Q: Is this a side-channel attack?
- No. Heckler is not a side-channel attack.
Q: What about other interrupt vectors?
- In Heckler, we focused on using interrupt vectors with handlers that had global effects. Please see our paper for a detailed analysis of the other interrupt vectors.
Q: How is this an Ahoi attack?
- Heckler abuses interrupts, a notification mechanism, to compromise CVMs making it an Ahoi attack.
Q: Why the name Heckler?
- To heckle is to interrupt a speaker with a derisive comment. Our attack interrupts the VM execution, acting like a “heckler” during a CVM execution.
Q: What was the response from hardware manufacturers?
Q: What was the response from cloud vendors?
Azure thanked us for the disclosure and communicated that both Azure Confidential Computing and Azure confidential VMs are not vulnerable because they use restricted and alternate injection modes supported by AMD SEV-SNP.
AWS thanked us for the disclosure and communicated the following:
- AWS is aware of CVE-2024-25742, CVE-2024-25743, and CVE-2024-25744, which describes issues related to AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP). These CVEs describe paths through which an untrusted hypervisor can inject interrupts into a virtualized guest running in an SEV-SNP environment to obtain data from the guest that it should not be able to read. Amazon EC2 does not rely on AMD SEV-SNP, Intel TDX, or similar affected technologies, to provide confidentiality and integrity protections to customers. The built-in hardware and associated firmware for confidentiality protections of the EC2 Nitro Systems are offered to all customers by default; these components are not affected by these issues. To support customers running Amazon Linux as virtualized guests using AMD SEV-SNP, we are working to release a kernel addressing the CVEs in the next release cycle.
Google thanked us for the disclosure and is investigating it. At the moment, they have neither confirmed nor denied the issue.
Authors
Responsible Disclosure
We informed Intel and AMD about int 0x80 on the 27th and 28th September 2023 respectively. We updated AMD on 14th October 2023 about our findings for other interrupts and our analysis of their defenses. At the request of AMD, we extended the embargo till 4 April 2024.
CVE
Heckler is tracked under the following CVEs:
Acknowledgments
Thanks to Intel, AMD, and Linux for the mitigation discussions and for developing the patches. We thank Benny Fuhry and Mona Vij from Intel for granting us early-access to TDX pre-production machines.
Next
WeSee