From c4e73784d27326783da34424b3f14ac467352194 Mon Sep 17 00:00:00 2001 From: Andrin Bertschi Date: Sat, 6 Apr 2024 19:18:38 +0200 Subject: [PATCH] update news --- 404.html | 317 +----------- blog/ahoi-overview/index.html | 441 +---------------- blog/index.html | 338 +------------ blog/index.xml | 21 +- blog/page/1/index.html | 12 +- blog/sitemap.xml | 11 +- categories/heckler/index.html | 346 +------------ categories/heckler/index.xml | 21 +- categories/heckler/page/1/index.html | 12 +- categories/index.html | 335 +------------ categories/index.xml | 28 +- categories/page/1/index.html | 12 +- categories/wesee/index.html | 346 +------------ categories/wesee/index.xml | 21 +- categories/wesee/page/1/index.html | 12 +- contributors/index.html | 319 +----------- contributors/index.xml | 13 +- contributors/page/1/index.html | 12 +- heckler/index.html | 660 ++----------------------- imprint/index.html | 407 +--------------- index.html | 533 +------------------- index.xml | 51 +- media/index.html | 378 +-------------- robots.txt | 2 +- sitemap.xml | 73 +-- tags/heckler/index.html | 346 +------------ tags/heckler/index.xml | 21 +- tags/heckler/page/1/index.html | 12 +- tags/index.html | 335 +------------ tags/index.xml | 28 +- tags/page/1/index.html | 12 +- tags/wesee/index.html | 346 +------------ tags/wesee/index.xml | 21 +- tags/wesee/page/1/index.html | 12 +- wesee/index.html | 695 ++------------------------- 35 files changed, 254 insertions(+), 6295 deletions(-) diff --git a/404.html b/404.html index 4a77de5..c5232e0 100644 --- a/404.html +++ b/404.html @@ -1,306 +1,11 @@ - - - - - - - - - - - - - - - -404 Page not found | Ahoi Attacks - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
- -
- - - - -
-
- - -
-
-
-

Page not found :(

-

The page you are looking for doesn't exist or has been moved.

-
-
-
- - -
-
- - - - - - - - - - - - - - - - - - \ No newline at end of file +404 Page not found | Ahoi Attacks +

Page not found :(

The page you are looking for doesn't exist or has been moved.

\ No newline at end of file diff --git a/blog/ahoi-overview/index.html b/blog/ahoi-overview/index.html index e53c55d..f5503b7 100644 --- a/blog/ahoi-overview/index.html +++ b/blog/ahoi-overview/index.html @@ -1,418 +1,23 @@ - - - - - - - - - - - - - - - -Overview of Ahoi Attacks | Ahoi Attacks - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
- -
- - - - -
-
- - -
-
-
-
-

Overview of Ahoi Attacks

-

- April 4, 2024 in heckler, wesee - - - - 4 minutes -

- -
-
-
-

Confidential Computing

-

Confidential computing, also referred to as trusted computing, trusted execution, or trusted execution environments (TEEs), enables users to outsource sensitive computation to untrusted cloud platforms without compromising security. To support this, hardware vendors provide trusted hardware that ensures that the user’s code and data remain protected from malicious tenants and malicious cloud service providers.

-

Today, users can provision confidential computing resources with process-level abstractions with technologies like Intel SGX with cloud service providers. In this model, a single Intel SGX enclave process is isolated by the trusted hardware from other processes (e.g., other applications, operating system).

-

To support a better cloud-native abstraction, there has been an increasing shift towards Confidential VMs (CVMs) where the trusted hardware provides VM-level isolation. With technologies like AMD SEV, Intel TDX, and ARM CCA users can deploy entire VMs and execute them such that they are not accessible to other tenants or the cloud service provider’s hardware (e.g., network devices) or software (e.g., hypervisor).

-

Interrupt delivery to Confidential VMs

-

In the CVM setting, the hypervisor is still responsible for most configuration and management tasks (e.g., memory management, scheduling), including interrupts. Ahoi attacks use notifications to break the security of CVMs. So, let’s understand how interrupt delivery, a form of notification, to CVMs typically works.

-

The guest OS executing inside the CVMs relies on interrupts for its operation (e.g., the guest Linux kernel requires timer interrupts for scheduling). To ensure that the guest OS continues to function, the hypervisor virtualizes the interrupt management and delivery to the CVMs. For this, the hypervisor hooks on all physical interrupts in the interrupt controller. For every interrupt, the hypervisor determines which VM should receive the interrupt, and sets up the interrupt controller to forward a virtual interrupt to the virtual CPU (vCPU). The guest OS of the CVM services the virtual interrupt by executing a handler. Finally, the handler of the guest OS acknowledges the interrupt.

-

Signal Delivery to Confidential VMs

-

In the x86 architecture, hardware exceptions are mapped to interrupt numbers between 0-31. For example, if an application performs a divide-by-zero, the hardware raises interrupt number 0 to the OS. Then, the OS converts interrupt 0 to a signal (SIGFPE) and delivers it to the user-space application. Now, the userspace application can register a custom handler for SIGFPE. For example, in the code snippet below, the compute_weighted function resorts to computing a non-weighted average if the operation results in a SIGFPE.

- - - -
-
-
- -
-
double arr[] = {...}
-double weights[] = {...}
-double avg = 0
-void handler() { /* compute non-weighted avg */ } 
-
-int compute_weighted() {
-  register(SIGFPE, handler)
-  avg = ...      /* compute weighted avg */ 
-  
-  return avg
-}  
-
-
-
-

Exploiting global effects of handlers

-

For Ahoi Attacks, an attacker can use the hypervisor to inject malicious interrupts to the victim’s vCPUs and trick it into executing the interrupt handlers. These interrupt handlers can have global effects (e.g., changing the register state in the application) that an attacker can trigger to compromise the victim’s CVM.

-

For example, consider an application that branches to an auth block based on the value of eax. The int 0x80 handler changes the value of eax to -4. An attacker injects int 0x80 before the test is performed as shown in the animation below. This changes the execution flow leading to successful authentication.

-

- - -Hecker int 0x80

-

The interrupts and signals we looked at so far trigger existing handlers that were programmed for a traditional setting where the hypervisor used to be trusted. But when used as-is in the confidential computing setting, this interface can be misused to launch an Ahoi attack. Check out our Heckler project for more details on how we break into AMD SEV-SNP and Intel TDX to remotely log in and gain sudo access to CVMs.

-

Another instance of an Ahoi attack is on a new interrupt interface introduced specially for confidential computing. In particular, AMD SEV introduces a new interrupt called VMM Communication Exception (#VC) to facilitate functionality where the hypervisor needs to access CVM’s memory. Since such accesses are forbidden, raising a #VC allows AMD SEV to handle such accesses (e.g., the hypervisor can fill in the processor details with the CVM executes a cpuid instruction). But this interface is also susceptible to the same pitfall. The hypervisor can arbitrarily raise #VC, even when the victim does not need to send or receive any information to the hypervisor. Since the victim CVM cannot distinguish between benign and malicious #VC, it always executes the VC handler that copies data in and out of the CVM depending on the reason for raising the #VC. The hypervisor controls the reason as well, making matters worse. Check out our WeSee project for more details on how we break into AMD SEV-SNP to perform arbitrary read, write, and code injection on CVMs.

- -
- heckler - wesee -
-
-
-
- - -
-
- - - - - - - - - - - - - - - - - - - \ No newline at end of file +Overview of Ahoi Attacks | Ahoi Attacks +

Overview of Ahoi Attacks

April 4, 2024 in heckler, wesee4 minutes

Confidential Computing

Confidential computing, also referred to as trusted computing, trusted execution, or trusted execution environments (TEEs), enables users to outsource sensitive computation to untrusted cloud platforms without compromising security. To support this, hardware vendors provide trusted hardware that ensures that the user’s code and data remain protected from malicious tenants and malicious cloud service providers.

Today, users can provision confidential computing resources with process-level abstractions with technologies like Intel SGX with cloud service providers. In this model, a single Intel SGX enclave process is isolated by the trusted hardware from other processes (e.g., other applications, operating system).

To support a better cloud-native abstraction, there has been an increasing shift towards Confidential VMs (CVMs) where the trusted hardware provides VM-level isolation. With technologies like AMD SEV, Intel TDX, and ARM CCA users can deploy entire VMs and execute them such that they are not accessible to other tenants or the cloud service provider’s hardware (e.g., network devices) or software (e.g., hypervisor).

Interrupt delivery to Confidential VMs

In the CVM setting, the hypervisor is still responsible for most configuration and management tasks (e.g., memory management, scheduling), including interrupts. Ahoi attacks use notifications to break the security of CVMs. So, let’s understand how interrupt delivery, a form of notification, to CVMs typically works.

The guest OS executing inside the CVMs relies on interrupts for its operation (e.g., the guest Linux kernel requires timer interrupts for scheduling). To ensure that the guest OS continues to function, the hypervisor virtualizes the interrupt management and delivery to the CVMs. For this, the hypervisor hooks on all physical interrupts in the interrupt controller. For every interrupt, the hypervisor determines which VM should receive the interrupt, and sets up the interrupt controller to forward a virtual interrupt to the virtual CPU (vCPU). The guest OS of the CVM services the virtual interrupt by executing a handler. Finally, the handler of the guest OS acknowledges the interrupt.

Signal Delivery to Confidential VMs

In the x86 architecture, hardware exceptions are mapped to interrupt numbers between 0-31. For example, if an application performs a divide-by-zero, the hardware raises interrupt number 0 to the OS. Then, the OS converts interrupt 0 to a signal (SIGFPE) and delivers it to the user-space application. Now, the userspace application can register a custom handler for SIGFPE. For example, in the code snippet below, the compute_weighted function resorts to computing a non-weighted average if the operation results in a SIGFPE.

double arr[] = {...}
+double weights[] = {...}
+double avg = 0
+void handler() { /* compute non-weighted avg */ } 
+
+int compute_weighted() {
+  register(SIGFPE, handler)
+  avg = ...      /* compute weighted avg */ 
+  
+  return avg
+}  
+

Exploiting global effects of handlers

For Ahoi Attacks, an attacker can use the hypervisor to inject malicious interrupts to the victim’s vCPUs and trick it into executing the interrupt handlers. These interrupt handlers can have global effects (e.g., changing the register state in the application) that an attacker can trigger to compromise the victim’s CVM.

For example, consider an application that branches to an auth block based on the value of eax. The int 0x80 handler changes the value of eax to -4. An attacker injects int 0x80 before the test is performed as shown in the animation below. This changes the execution flow leading to successful authentication.

Hecker int 0x80

The interrupts and signals we looked at so far trigger existing handlers that were programmed for a traditional setting where the hypervisor used to be trusted. But when used as-is in the confidential computing setting, this interface can be misused to launch an Ahoi attack. Check out our Heckler project for more details on how we break into AMD SEV-SNP and Intel TDX to remotely log in and gain sudo access to CVMs.

Another instance of an Ahoi attack is on a new interrupt interface introduced specially for confidential computing. In particular, AMD SEV introduces a new interrupt called VMM Communication Exception (#VC) to facilitate functionality where the hypervisor needs to access CVM’s memory. Since such accesses are forbidden, raising a #VC allows AMD SEV to handle such accesses (e.g., the hypervisor can fill in the processor details with the CVM executes a cpuid instruction). But this interface is also susceptible to the same pitfall. The hypervisor can arbitrarily raise #VC, even when the victim does not need to send or receive any information to the hypervisor. Since the victim CVM cannot distinguish between benign and malicious #VC, it always executes the VC handler that copies data in and out of the CVM depending on the reason for raising the #VC. The hypervisor controls the reason as well, making matters worse. Check out our WeSee project for more details on how we break into AMD SEV-SNP to perform arbitrary read, write, and code injection on CVMs.

\ No newline at end of file diff --git a/blog/index.html b/blog/index.html index 70d692e..6e3ca15 100644 --- a/blog/index.html +++ b/blog/index.html @@ -1,327 +1,11 @@ - - - - - - - - - - - - - - - -Ahoi Attacks Blog | Ahoi Attacks - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
- -
- - - - -
-
- - -
-
-

Ahoi Attacks Blog

-
-
-
-
-
-
- -
-
-
-
-
-
- -
-
- - -
-
- - - - - - - - - - - - - - - - - - \ No newline at end of file +Ahoi Attacks Blog | Ahoi Attacks +

Ahoi Attacks Blog

\ No newline at end of file diff --git a/blog/index.xml b/blog/index.xml index 2d3ce32..bd5e6f8 100644 --- a/blog/index.xml +++ b/blog/index.xml @@ -1,20 +1 @@ - - - - Ahoi Attacks Blog on Ahoi Attacks - http://localhost:1313/blog/ - Recent content in Ahoi Attacks Blog on Ahoi Attacks - Hugo -- gohugo.io - en - Copyright (c) Secure & Trustworthy System Group - Thu, 04 Apr 2024 00:04:48 +0200 - - - Overview of Ahoi Attacks - http://localhost:1313/blog/ahoi-overview/ - Thu, 04 Apr 2024 00:04:48 +0200 - http://localhost:1313/blog/ahoi-overview/ - Confidential Computing Confidential computing, also referred to as trusted computing, trusted execution, or trusted execution environments (TEEs), enables users to outsource sensitive computation to untrusted cloud platforms without compromising security. - - - +Ahoi Attacks Blog on Ahoi Attackshttps://ahoi-attacks.github.io/blog/Recent content in Ahoi Attacks Blog on Ahoi AttacksHugo -- gohugo.ioenCopyright (c) Secure & Trustworthy System GroupThu, 04 Apr 2024 00:04:48 +0200Overview of Ahoi Attackshttps://ahoi-attacks.github.io/blog/ahoi-overview/Thu, 04 Apr 2024 00:04:48 +0200https://ahoi-attacks.github.io/blog/ahoi-overview/Confidential Computing Confidential computing, also referred to as trusted computing, trusted execution, or trusted execution environments (TEEs), enables users to outsource sensitive computation to untrusted cloud platforms without compromising security. \ No newline at end of file diff --git a/blog/page/1/index.html b/blog/page/1/index.html index a541f84..af5f27b 100644 --- a/blog/page/1/index.html +++ b/blog/page/1/index.html @@ -1,10 +1,2 @@ - - - - http://localhost:1313/blog/ - - - - - - +https://ahoi-attacks.github.io/blog/ + \ No newline at end of file diff --git a/blog/sitemap.xml b/blog/sitemap.xml index 39f24f7..3b7c444 100644 --- a/blog/sitemap.xml +++ b/blog/sitemap.xml @@ -1,10 +1 @@ - - - - http://localhost:1313/blog/ahoi-overview/ - 2024-04-04T00:04:48+02:00 - monthly - 0.5 - - \ No newline at end of file +https://ahoi-attacks.github.io/blog/ahoi-overview/2024-04-04T00:04:48+02:00monthly0.5 \ No newline at end of file diff --git a/categories/heckler/index.html b/categories/heckler/index.html index 83ab5e0..ada2814 100644 --- a/categories/heckler/index.html +++ b/categories/heckler/index.html @@ -1,335 +1,11 @@ - - - - - - - - - - - - - - - -Heckler | Ahoi Attacks - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
- -
- - - - -
-
- - -
-
- -

Heckler

-
-
-
-
-
-
- -
-
-
-
-
-
- -
-
- - -
-
- - - - - - - - - - - - - - - - - - \ No newline at end of file +Heckler | Ahoi Attacks +

Heckler

\ No newline at end of file diff --git a/categories/heckler/index.xml b/categories/heckler/index.xml index 29db6ec..2c955b3 100644 --- a/categories/heckler/index.xml +++ b/categories/heckler/index.xml @@ -1,20 +1 @@ - - - - Heckler on Ahoi Attacks - http://localhost:1313/categories/heckler/ - Recent content in Heckler on Ahoi Attacks - Hugo -- gohugo.io - en - Copyright (c) Secure & Trustworthy System Group - Thu, 04 Apr 2024 00:04:48 +0200 - - - Overview of Ahoi Attacks - http://localhost:1313/blog/ahoi-overview/ - Thu, 04 Apr 2024 00:04:48 +0200 - http://localhost:1313/blog/ahoi-overview/ - Confidential Computing Confidential computing, also referred to as trusted computing, trusted execution, or trusted execution environments (TEEs), enables users to outsource sensitive computation to untrusted cloud platforms without compromising security. - - - +Heckler on Ahoi Attackshttps://ahoi-attacks.github.io/categories/heckler/Recent content in Heckler on Ahoi AttacksHugo -- gohugo.ioenCopyright (c) Secure & Trustworthy System GroupThu, 04 Apr 2024 00:04:48 +0200Overview of Ahoi Attackshttps://ahoi-attacks.github.io/blog/ahoi-overview/Thu, 04 Apr 2024 00:04:48 +0200https://ahoi-attacks.github.io/blog/ahoi-overview/Confidential Computing Confidential computing, also referred to as trusted computing, trusted execution, or trusted execution environments (TEEs), enables users to outsource sensitive computation to untrusted cloud platforms without compromising security. \ No newline at end of file diff --git a/categories/heckler/page/1/index.html b/categories/heckler/page/1/index.html index dba816b..5ff254c 100644 --- a/categories/heckler/page/1/index.html +++ b/categories/heckler/page/1/index.html @@ -1,10 +1,2 @@ - - - - http://localhost:1313/categories/heckler/ - - - - - - +https://ahoi-attacks.github.io/categories/heckler/ + \ No newline at end of file diff --git a/categories/index.html b/categories/index.html index 01680ac..dfdff11 100644 --- a/categories/index.html +++ b/categories/index.html @@ -1,324 +1,11 @@ - - - - - - - - - - - - - - - -Categories | Ahoi Attacks - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
- -
- - - - -
-
- - -
-
-

Categories

-
-
- -
-
- -
-
- -
-
- -
-
- -
- -
-
- - -
-
- - - - - - - - - - - - - - - - - - \ No newline at end of file +Categories | Ahoi Attacks +

Categories

\ No newline at end of file diff --git a/categories/index.xml b/categories/index.xml index a89f049..979e371 100644 --- a/categories/index.xml +++ b/categories/index.xml @@ -1,27 +1 @@ - - - - Categories on Ahoi Attacks - http://localhost:1313/categories/ - Recent content in Categories on Ahoi Attacks - Hugo -- gohugo.io - en - Copyright (c) Secure & Trustworthy System Group - Thu, 04 Apr 2024 00:04:48 +0200 - - - Heckler - http://localhost:1313/categories/heckler/ - Thu, 04 Apr 2024 00:04:48 +0200 - http://localhost:1313/categories/heckler/ - - - - Wesee - http://localhost:1313/categories/wesee/ - Thu, 04 Apr 2024 00:04:48 +0200 - http://localhost:1313/categories/wesee/ - - - - +Categories on Ahoi Attackshttps://ahoi-attacks.github.io/categories/Recent content in Categories on Ahoi AttacksHugo -- gohugo.ioenCopyright (c) Secure & Trustworthy System GroupThu, 04 Apr 2024 00:04:48 +0200Hecklerhttps://ahoi-attacks.github.io/categories/heckler/Thu, 04 Apr 2024 00:04:48 +0200https://ahoi-attacks.github.io/categories/heckler/Weseehttps://ahoi-attacks.github.io/categories/wesee/Thu, 04 Apr 2024 00:04:48 +0200https://ahoi-attacks.github.io/categories/wesee/ \ No newline at end of file diff --git a/categories/page/1/index.html b/categories/page/1/index.html index b7ea490..4f7968c 100644 --- a/categories/page/1/index.html +++ b/categories/page/1/index.html @@ -1,10 +1,2 @@ - - - - http://localhost:1313/categories/ - - - - - - +https://ahoi-attacks.github.io/categories/ + \ No newline at end of file diff --git a/categories/wesee/index.html b/categories/wesee/index.html index 31936a4..dad7eca 100644 --- a/categories/wesee/index.html +++ b/categories/wesee/index.html @@ -1,335 +1,11 @@ - - - - - - - - - - - - - - - -Wesee | Ahoi Attacks - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
- -
- - - - -
-
- - -
-
- -

Wesee

-
-
-
-
-
-
- -
-
-
-
-
-
- -
-
- - -
-
- - - - - - - - - - - - - - - - - - \ No newline at end of file +Wesee | Ahoi Attacks +

Wesee

\ No newline at end of file diff --git a/categories/wesee/index.xml b/categories/wesee/index.xml index 602ed09..e5ac5a1 100644 --- a/categories/wesee/index.xml +++ b/categories/wesee/index.xml @@ -1,20 +1 @@ - - - - Wesee on Ahoi Attacks - http://localhost:1313/categories/wesee/ - Recent content in Wesee on Ahoi Attacks - Hugo -- gohugo.io - en - Copyright (c) Secure & Trustworthy System Group - Thu, 04 Apr 2024 00:04:48 +0200 - - - Overview of Ahoi Attacks - http://localhost:1313/blog/ahoi-overview/ - Thu, 04 Apr 2024 00:04:48 +0200 - http://localhost:1313/blog/ahoi-overview/ - Confidential Computing Confidential computing, also referred to as trusted computing, trusted execution, or trusted execution environments (TEEs), enables users to outsource sensitive computation to untrusted cloud platforms without compromising security. - - - +Wesee on Ahoi Attackshttps://ahoi-attacks.github.io/categories/wesee/Recent content in Wesee on Ahoi AttacksHugo -- gohugo.ioenCopyright (c) Secure & Trustworthy System GroupThu, 04 Apr 2024 00:04:48 +0200Overview of Ahoi Attackshttps://ahoi-attacks.github.io/blog/ahoi-overview/Thu, 04 Apr 2024 00:04:48 +0200https://ahoi-attacks.github.io/blog/ahoi-overview/Confidential Computing Confidential computing, also referred to as trusted computing, trusted execution, or trusted execution environments (TEEs), enables users to outsource sensitive computation to untrusted cloud platforms without compromising security. \ No newline at end of file diff --git a/categories/wesee/page/1/index.html b/categories/wesee/page/1/index.html index d07bc6c..6434cc8 100644 --- a/categories/wesee/page/1/index.html +++ b/categories/wesee/page/1/index.html @@ -1,10 +1,2 @@ - - - - http://localhost:1313/categories/wesee/ - - - - - - +https://ahoi-attacks.github.io/categories/wesee/ + \ No newline at end of file diff --git a/contributors/index.html b/contributors/index.html index e1b31bc..751dfa4 100644 --- a/contributors/index.html +++ b/contributors/index.html @@ -1,308 +1,11 @@ - - - - - - - - - - - - - - - -Contributors | Ahoi Attacks - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
- -
- - - - -
-
- - -
-
-

Contributors

-
-
- -
- -
-
- - -
-
- - - - - - - - - - - - - - - - - - \ No newline at end of file +Contributors | Ahoi Attacks +

Contributors

\ No newline at end of file diff --git a/contributors/index.xml b/contributors/index.xml index da7dc65..4acfbca 100644 --- a/contributors/index.xml +++ b/contributors/index.xml @@ -1,12 +1 @@ - - - - Contributors on Ahoi Attacks - http://localhost:1313/contributors/ - Recent content in Contributors on Ahoi Attacks - Hugo -- gohugo.io - en - Copyright (c) Secure & Trustworthy System Group - - - +Contributors on Ahoi Attackshttps://ahoi-attacks.github.io/contributors/Recent content in Contributors on Ahoi AttacksHugo -- gohugo.ioenCopyright (c) Secure & Trustworthy System Group \ No newline at end of file diff --git a/contributors/page/1/index.html b/contributors/page/1/index.html index b02b9c6..cb2feb4 100644 --- a/contributors/page/1/index.html +++ b/contributors/page/1/index.html @@ -1,10 +1,2 @@ - - - - http://localhost:1313/contributors/ - - - - - - +https://ahoi-attacks.github.io/contributors/ + \ No newline at end of file diff --git a/heckler/index.html b/heckler/index.html index f9d2a6f..15dbc19 100644 --- a/heckler/index.html +++ b/heckler/index.html @@ -1,362 +1,26 @@ - - - - - - - - - - - - - - - -Heckler - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
- -
- - - - -
-
- - -
- - -
-
- - - - -
-
- -
-

Heckler

-

Breaking Confidential VMs with Malicious Interrupts
(to appear at USENIX Security 2024)

-
-
-
- Paper -
-
-
-
- Source -
-
-
-
- CVE -
-
-
-
-

How Does It Work?

-

AMD SEV-SNP and Intel TDX enable Confidential VMs (CVMs). With these CVMs, the +Heckler +

Heckler

Breaking Confidential VMs with Malicious Interrupts
(to appear at USENIX Security 2024)

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 +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 +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 @@ -365,173 +29,43 @@

Int 0x80

-

The OS converts different hardware exceptions to signals that are delivered to +malicious hypervisor to bypass authentication checks (e.g., OpenSSH, sudo).

Heckler Int80

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

-

- - -Heckler Signals

-

Breaking into CVMs with Heckler

-

OpenSSH

-

Using Heckler, we attack OpenSSH v9.4.P1+ to compromise its authentication and +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.

Heckler Signals

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.

-

- - -Heckler Gadgets

-

Specifically, OpenSSH calls mm_answer_authpassword to decide if authentication +shell.

Heckler Gadgets

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 0x80 is used to invoke legacy 32-bit system calls. This instruction +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 0x80 is 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 the int 0x80 instruction. Therefore, all application binaries are vulnerable to Heckler if they execute with a Linux -kernel that registers a vulnerable int 0x80 handler.
    • -
    -
    -
    - Q: Does Heckler affect non-confidential VMs that I have in the cloud? -
      -
    • No. Heckler assumes a malicious hypervisor to inject interrupts. For normal +kernel that registers a vulnerable int 0x80 handler.
    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? -
    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 0x80 is 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 0x80 handler. -Currently, there is no fix to protect against Heckler’s signal attacks.

      -
    • -
    • -

      For robust defense, we recommend that cloud users switch to protected interrupt +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? -
      -
    • Intel and AMD acknowledged the attacks but concluded that this is a -vulnerability in the third-party software implementations of SEV-SNP and TDX.
    • -
    -
    -
    - Q: What was the response from cloud vendors? -
      -
    • -

      Azure thanked us for the disclosure and communicated that both Azure +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?
    • Intel and AMD acknowledged the attacks but concluded that this is a +vulnerability in the third-party software implementations of SEV-SNP and TDX.
    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 +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 @@ -542,135 +76,11 @@

          FAQ

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

    - - - - - -
    - -
    - - -
    -
    - - - - - - - - - - - - - - - - - - \ No newline at end of file +granting us early-access to TDX pre-production machines.

    \ No newline at end of file diff --git a/imprint/index.html b/imprint/index.html index 1f6d150..35455fc 100644 --- a/imprint/index.html +++ b/imprint/index.html @@ -1,273 +1,14 @@ - - - - - - - - - - - - - - - -Imprint | Ahoi Attacks - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    -
    - -
    - - - - -
    -
    - - -
    - -
    - - - -

    Imprint

    - - - -
    -
    -
    - -
    -
    
    +Imprint | Ahoi Attacks
    +

    Imprint

    
       Prof. Dr. Shweta Shinde  
       CAB F 71.2
       shweta.shinde@inf.ethz.ch
    @@ -276,127 +17,5 @@ 

    Imprint

    - - - - - -
    - -
    - - -
    -
    - - - - - - - - - - - - - - - - - - \ No newline at end of file +
    \ No newline at end of file diff --git a/index.html b/index.html index ed37703..513fb81 100644 --- a/index.html +++ b/index.html @@ -1,518 +1,15 @@ - - - - - - - - - - - - - - - - -Ahoi Attacks - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    -
    - -
    - - - - -
    -
    - - - -
    -
    -
    -

    Disrupting TEEs with Malicious Notifications

    -
    -
    -

    Ahoi Attacks is a family of attacks on Hardware-based Trusted Execution Environments (TEEs) to break AMD SEV-SNP and Intel TDX.

    - -
    -
    -
    - - -
    -
    - -
    -
    -
    -
    -
    - -
    - -
    - -
    -
    -
    - -
    -
    -
    - -
    -

    -
    Heckler
    - -

    -

    Breaking Confidential VMs with Malicious Interrupts

    - -
    -
    - - - - - - -
    -
    -
    -
    -
    - -
    -
    -
    - -
    -
    -
    - - - -
    -

    -
    WeSee
    - -

    -

    Using Malicious #VC Interrupts to Break AMD SEV-SNP

    - -
    -
    - - - - - - -
    -
    -
    -
    -
    -
    -
    -
    - - - - -
    -
    -
    - -
    -
    -
    -
    -
    -
    -
    - Defining -
    -
    - -
    -
    -

    Ahoi Attacks

    -

    /əˈhɔɪ əˈtaks/

    -
    -
    -
    - noun
    -
      - a family of attacks that compromise TEEs using malicious notifications. -   -
    -
    -
    - -
    -
    -
    -
    -
    -
    - - -
    -
    -
    -
    -
    -
    -

    Why the name Ahoi?

    - Ahoy is a word used to call a ship or boat. It is often used today in playful imitations - of pirate speak. We coin the term Ahoi - (sounds like Ahoy) which is an anagram of 1 edit distance from Iago as - an homage to classical works that studied interface attacks with TEEs. - -

    - Tell Me More -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    - -

    Ahoi Attacks: An Analogy

    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    - -

    Ahoi Attacks: An Explainer

    - - -
    -
    -
    -
    -
    -
    -
    -
    -
    - - - - - - - - - - - - - - - - - - \ No newline at end of file +Ahoi Attacks +

    Disrupting TEEs with Malicious Notifications

    Ahoi Attacks is a family of attacks on Hardware-based Trusted Execution Environments (TEEs) to break AMD SEV-SNP and Intel TDX.

    Heckler

    Breaking Confidential VMs with Malicious Interrupts

    WeSee

    Using Malicious #VC Interrupts to Break AMD SEV-SNP

    Defining

    Ahoi Attacks

    /əˈhɔɪ əˈtaks/

    noun
      a family of attacks that compromise TEEs using malicious notifications. + 

    Why the name Ahoi?

    Ahoy is a word used to call a ship or boat. It is often used today in playful imitations +of pirate speak. We coin the term Ahoi +(sounds like Ahoy) which is an anagram of 1 edit distance from Iago as +an homage to classical works that studied interface attacks with TEEs.

    Tell Me More

    Ahoi Attacks: An Analogy

    Ahoi Attacks: An Explainer

    \ No newline at end of file diff --git a/index.xml b/index.xml index 9e467ab..2450875 100644 --- a/index.xml +++ b/index.xml @@ -1,48 +1,3 @@ - - - - Ahoi Attacks - http://localhost:1313/ - Recent content on Ahoi Attacks - Hugo -- gohugo.io - en - Copyright (c) Secure & Trustworthy System Group - Thu, 04 Apr 2024 00:04:48 +0200 - - - Overview of Ahoi Attacks - http://localhost:1313/blog/ahoi-overview/ - Thu, 04 Apr 2024 00:04:48 +0200 - http://localhost:1313/blog/ahoi-overview/ - Confidential Computing Confidential computing, also referred to as trusted computing, trusted execution, or trusted execution environments (TEEs), enables users to outsource sensitive computation to untrusted cloud platforms without compromising security. - - - Heckler - http://localhost:1313/heckler/ - Thu, 04 Apr 2024 00:04:48 +0200 - http://localhost:1313/heckler/ - Heckler: Breaking Confidential VMs with Malicious Interrupts - - - WeSee - http://localhost:1313/wesee/ - Thu, 04 Apr 2024 00:04:48 +0200 - http://localhost:1313/wesee/ - WeSee Using Malicious #VC Interrupts to Break AMD SEV-SNP (to appear at IEEE S&P 2024) Paper Source CVE How Does It Work? - - - Imprint - http://localhost:1313/imprint/ - Mon, 01 Jan 0001 00:00:00 +0000 - http://localhost:1313/imprint/ - Imprint Prof. Dr. Shweta Shinde CAB F 71.2 shweta.shinde@inf.ethz.ch Dep. Informatik Universitätstrasse 6 8092 Zürich Switzerland Disclaimer & Copyright Data Protection - - - Media Coverage - http://localhost:1313/media/ - Mon, 01 Jan 0001 00:00:00 +0000 - http://localhost:1313/media/ - Media Coverage Ahoi Attacks in the News: ETH News Article (English): Knocking cloud security off its game ETH News Article (German): Die Cloud-Sicherheit aus dem Konzept gebracht - - - +Ahoi Attackshttps://ahoi-attacks.github.io/Recent content on Ahoi AttacksHugo -- gohugo.ioenCopyright (c) Secure & Trustworthy System GroupThu, 04 Apr 2024 00:04:48 +0200Overview of Ahoi Attackshttps://ahoi-attacks.github.io/blog/ahoi-overview/Thu, 04 Apr 2024 00:04:48 +0200https://ahoi-attacks.github.io/blog/ahoi-overview/Confidential Computing Confidential computing, also referred to as trusted computing, trusted execution, or trusted execution environments (TEEs), enables users to outsource sensitive computation to untrusted cloud platforms without compromising security.Hecklerhttps://ahoi-attacks.github.io/heckler/Thu, 04 Apr 2024 00:04:48 +0200https://ahoi-attacks.github.io/heckler/Heckler: Breaking Confidential VMs with Malicious InterruptsWeSeehttps://ahoi-attacks.github.io/wesee/Thu, 04 Apr 2024 00:04:48 +0200https://ahoi-attacks.github.io/wesee/WeSee Using Malicious #VC Interrupts to Break AMD SEV-SNP (to appear at IEEE S&P 2024) +Paper Source CVE How Does It Work?Imprinthttps://ahoi-attacks.github.io/imprint/Mon, 01 Jan 0001 00:00:00 +0000https://ahoi-attacks.github.io/imprint/Imprint Prof. Dr. Shweta Shinde CAB F 71.2 shweta.shinde@inf.ethz.ch Dep. Informatik Universitätstrasse 6 8092 Zürich Switzerland Disclaimer & Copyright Data ProtectionMedia Coveragehttps://ahoi-attacks.github.io/media/Mon, 01 Jan 0001 00:00:00 +0000https://ahoi-attacks.github.io/media/Media Coverage Ahoi Attacks in the News: +ETH News Article (English): Knocking cloud security off its game ETH News Article (German): Die Cloud-Sicherheit aus dem Konzept gebracht \ No newline at end of file diff --git a/media/index.html b/media/index.html index 2184903..fb6c0bc 100644 --- a/media/index.html +++ b/media/index.html @@ -1,366 +1,12 @@ - - - - - - - - - - - - - - - -Media Coverage | Ahoi Attacks - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    -
    - -
    - - - - -
    -
    - - -
    - -
    - - - -

    Media Coverage

    -

    Ahoi Attacks in the News:

    - - - - - - -
    - -
    - - -
    -
    - - - - - - - - - - - - - - - - - - \ No newline at end of file +Media Coverage | Ahoi Attacks +

    Media Coverage

    Ahoi Attacks in the News:

    \ No newline at end of file diff --git a/robots.txt b/robots.txt index 723f408..1cb9a09 100644 --- a/robots.txt +++ b/robots.txt @@ -1,3 +1,3 @@ User-agent: * Disallow: /admin/ -Sitemap: http://localhost:1313/sitemap.xml +Sitemap: https://ahoi-attacks.github.io/sitemap.xml diff --git a/sitemap.xml b/sitemap.xml index d3af983..36ffbc5 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -1,72 +1 @@ - - - - http://localhost:1313/blog/ahoi-overview/ - 2024-04-04T00:04:48+02:00 - monthly - 0.5 - - http://localhost:1313/blog/ - 2024-04-01T16:21:44+02:00 - monthly - 0.5 - - http://localhost:1313/heckler/ - 2024-04-04T00:04:48+02:00 - monthly - 0.5 - - http://localhost:1313/wesee/ - 2024-04-04T00:04:48+02:00 - monthly - 0.5 - - http://localhost:1313/categories/ - 2024-04-04T00:04:48+02:00 - monthly - 0.5 - - http://localhost:1313/tags/heckler/ - 2024-04-04T00:04:48+02:00 - monthly - 0.5 - - http://localhost:1313/categories/heckler/ - 2024-04-04T00:04:48+02:00 - monthly - 0.5 - - http://localhost:1313/tags/ - 2024-04-04T00:04:48+02:00 - monthly - 0.5 - - http://localhost:1313/tags/wesee/ - 2024-04-04T00:04:48+02:00 - monthly - 0.5 - - http://localhost:1313/categories/wesee/ - 2024-04-04T00:04:48+02:00 - monthly - 0.5 - - http://localhost:1313/ - 2023-09-07T16:33:54+02:00 - monthly - 0.5 - - http://localhost:1313/contributors/ - monthly - 0.5 - - http://localhost:1313/imprint/ - monthly - 0.5 - - http://localhost:1313/media/ - monthly - 0.5 - - +https://ahoi-attacks.github.io/blog/ahoi-overview/2024-04-04T00:04:48+02:00monthly0.5https://ahoi-attacks.github.io/blog/2024-04-01T16:21:44+02:00monthly0.5https://ahoi-attacks.github.io/heckler/2024-04-04T00:04:48+02:00monthly0.5https://ahoi-attacks.github.io/wesee/2024-04-04T00:04:48+02:00monthly0.5https://ahoi-attacks.github.io/categories/2024-04-04T00:04:48+02:00monthly0.5https://ahoi-attacks.github.io/tags/heckler/2024-04-04T00:04:48+02:00monthly0.5https://ahoi-attacks.github.io/categories/heckler/2024-04-04T00:04:48+02:00monthly0.5https://ahoi-attacks.github.io/tags/2024-04-04T00:04:48+02:00monthly0.5https://ahoi-attacks.github.io/tags/wesee/2024-04-04T00:04:48+02:00monthly0.5https://ahoi-attacks.github.io/categories/wesee/2024-04-04T00:04:48+02:00monthly0.5https://ahoi-attacks.github.io/2023-09-07T16:33:54+02:00monthly0.5https://ahoi-attacks.github.io/contributors/monthly0.5https://ahoi-attacks.github.io/imprint/monthly0.5https://ahoi-attacks.github.io/media/monthly0.5 \ No newline at end of file diff --git a/tags/heckler/index.html b/tags/heckler/index.html index 55def34..550a7d2 100644 --- a/tags/heckler/index.html +++ b/tags/heckler/index.html @@ -1,335 +1,11 @@ - - - - - - - - - - - - - - - -Heckler | Ahoi Attacks - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    -
    - -
    - - - - -
    -
    - - -
    -
    - -

    Heckler

    -
    -
    -
    -
    -
    -
    - -
    -
    -
    -
    -
    -
    - -
    -
    - - -
    -
    - - - - - - - - - - - - - - - - - - \ No newline at end of file +Heckler | Ahoi Attacks +

    Heckler

    \ No newline at end of file diff --git a/tags/heckler/index.xml b/tags/heckler/index.xml index ff5c2b0..f4713db 100644 --- a/tags/heckler/index.xml +++ b/tags/heckler/index.xml @@ -1,20 +1 @@ - - - - Heckler on Ahoi Attacks - http://localhost:1313/tags/heckler/ - Recent content in Heckler on Ahoi Attacks - Hugo -- gohugo.io - en - Copyright (c) Secure & Trustworthy System Group - Thu, 04 Apr 2024 00:04:48 +0200 - - - Overview of Ahoi Attacks - http://localhost:1313/blog/ahoi-overview/ - Thu, 04 Apr 2024 00:04:48 +0200 - http://localhost:1313/blog/ahoi-overview/ - Confidential Computing Confidential computing, also referred to as trusted computing, trusted execution, or trusted execution environments (TEEs), enables users to outsource sensitive computation to untrusted cloud platforms without compromising security. - - - +Heckler on Ahoi Attackshttps://ahoi-attacks.github.io/tags/heckler/Recent content in Heckler on Ahoi AttacksHugo -- gohugo.ioenCopyright (c) Secure & Trustworthy System GroupThu, 04 Apr 2024 00:04:48 +0200Overview of Ahoi Attackshttps://ahoi-attacks.github.io/blog/ahoi-overview/Thu, 04 Apr 2024 00:04:48 +0200https://ahoi-attacks.github.io/blog/ahoi-overview/Confidential Computing Confidential computing, also referred to as trusted computing, trusted execution, or trusted execution environments (TEEs), enables users to outsource sensitive computation to untrusted cloud platforms without compromising security. \ No newline at end of file diff --git a/tags/heckler/page/1/index.html b/tags/heckler/page/1/index.html index 0a3e09a..f8253ed 100644 --- a/tags/heckler/page/1/index.html +++ b/tags/heckler/page/1/index.html @@ -1,10 +1,2 @@ - - - - http://localhost:1313/tags/heckler/ - - - - - - +https://ahoi-attacks.github.io/tags/heckler/ + \ No newline at end of file diff --git a/tags/index.html b/tags/index.html index 5175015..9386a40 100644 --- a/tags/index.html +++ b/tags/index.html @@ -1,324 +1,11 @@ - - - - - - - - - - - - - - - -Tags | Ahoi Attacks - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    -
    - -
    - - - - -
    -
    - - -
    -
    -

    Tags

    -
    -
    - -
    -
    - -
    -
    - -
    -
    - -
    -
    - -
    - -
    -
    - - -
    -
    - - - - - - - - - - - - - - - - - - \ No newline at end of file +Tags | Ahoi Attacks +

    Tags

    \ No newline at end of file diff --git a/tags/index.xml b/tags/index.xml index 9cdb0e9..b0a7b33 100644 --- a/tags/index.xml +++ b/tags/index.xml @@ -1,27 +1 @@ - - - - Tags on Ahoi Attacks - http://localhost:1313/tags/ - Recent content in Tags on Ahoi Attacks - Hugo -- gohugo.io - en - Copyright (c) Secure & Trustworthy System Group - Thu, 04 Apr 2024 00:04:48 +0200 - - - Heckler - http://localhost:1313/tags/heckler/ - Thu, 04 Apr 2024 00:04:48 +0200 - http://localhost:1313/tags/heckler/ - - - - Wesee - http://localhost:1313/tags/wesee/ - Thu, 04 Apr 2024 00:04:48 +0200 - http://localhost:1313/tags/wesee/ - - - - +Tags on Ahoi Attackshttps://ahoi-attacks.github.io/tags/Recent content in Tags on Ahoi AttacksHugo -- gohugo.ioenCopyright (c) Secure & Trustworthy System GroupThu, 04 Apr 2024 00:04:48 +0200Hecklerhttps://ahoi-attacks.github.io/tags/heckler/Thu, 04 Apr 2024 00:04:48 +0200https://ahoi-attacks.github.io/tags/heckler/Weseehttps://ahoi-attacks.github.io/tags/wesee/Thu, 04 Apr 2024 00:04:48 +0200https://ahoi-attacks.github.io/tags/wesee/ \ No newline at end of file diff --git a/tags/page/1/index.html b/tags/page/1/index.html index 09165a4..44789f2 100644 --- a/tags/page/1/index.html +++ b/tags/page/1/index.html @@ -1,10 +1,2 @@ - - - - http://localhost:1313/tags/ - - - - - - +https://ahoi-attacks.github.io/tags/ + \ No newline at end of file diff --git a/tags/wesee/index.html b/tags/wesee/index.html index 8e445a1..4371a90 100644 --- a/tags/wesee/index.html +++ b/tags/wesee/index.html @@ -1,335 +1,11 @@ - - - - - - - - - - - - - - - -Wesee | Ahoi Attacks - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    -
    - -
    - - - - -
    -
    - - -
    -
    - -

    Wesee

    -
    -
    -
    -
    -
    -
    - -
    -
    -
    -
    -
    -
    - -
    -
    - - -
    -
    - - - - - - - - - - - - - - - - - - \ No newline at end of file +Wesee | Ahoi Attacks +

    Wesee

    \ No newline at end of file diff --git a/tags/wesee/index.xml b/tags/wesee/index.xml index 1523a2f..0732c32 100644 --- a/tags/wesee/index.xml +++ b/tags/wesee/index.xml @@ -1,20 +1 @@ - - - - Wesee on Ahoi Attacks - http://localhost:1313/tags/wesee/ - Recent content in Wesee on Ahoi Attacks - Hugo -- gohugo.io - en - Copyright (c) Secure & Trustworthy System Group - Thu, 04 Apr 2024 00:04:48 +0200 - - - Overview of Ahoi Attacks - http://localhost:1313/blog/ahoi-overview/ - Thu, 04 Apr 2024 00:04:48 +0200 - http://localhost:1313/blog/ahoi-overview/ - Confidential Computing Confidential computing, also referred to as trusted computing, trusted execution, or trusted execution environments (TEEs), enables users to outsource sensitive computation to untrusted cloud platforms without compromising security. - - - +Wesee on Ahoi Attackshttps://ahoi-attacks.github.io/tags/wesee/Recent content in Wesee on Ahoi AttacksHugo -- gohugo.ioenCopyright (c) Secure & Trustworthy System GroupThu, 04 Apr 2024 00:04:48 +0200Overview of Ahoi Attackshttps://ahoi-attacks.github.io/blog/ahoi-overview/Thu, 04 Apr 2024 00:04:48 +0200https://ahoi-attacks.github.io/blog/ahoi-overview/Confidential Computing Confidential computing, also referred to as trusted computing, trusted execution, or trusted execution environments (TEEs), enables users to outsource sensitive computation to untrusted cloud platforms without compromising security. \ No newline at end of file diff --git a/tags/wesee/page/1/index.html b/tags/wesee/page/1/index.html index d72ebd0..7e5bf11 100644 --- a/tags/wesee/page/1/index.html +++ b/tags/wesee/page/1/index.html @@ -1,10 +1,2 @@ - - - - http://localhost:1313/tags/wesee/ - - - - - - +https://ahoi-attacks.github.io/tags/wesee/ + \ No newline at end of file diff --git a/wesee/index.html b/wesee/index.html index a9e945a..7a6e04e 100644 --- a/wesee/index.html +++ b/wesee/index.html @@ -1,531 +1,27 @@ - - - - - - - - - - - - - - - -WeSee - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    -
    - -
    - - - - -
    -
    - - -
    - - -
    -
    - - - - -
    -
    - - -
    -

    WeSee

    -

    Using Malicious #VC Interrupts to Break AMD SEV-SNP
    (to appear at IEEE S&P 2024)

    -
    -
    -
    - Paper -
    -
    -
    -
    - Source -
    -
    -
    -
    - CVE -
    -
    -
    -
    -

    How Does It Work?

    -

    AMD SEV-SNP enables the creation of Confidential VMs (CVMs). This setting assumes a malicious hypervisor that cannot directly access the CVM’s memory. In a non-confidential setting, the hypervisor performs different operations (e.g., service hypercalls) that are important for the functionality of the applications. To support this functionality in the presence of a malicious hypervisor, AMD SEV introduces a new VMM Communication exception (#VC).

    -

    #VC without an attacker: -Let’s first look at how #VC is handled during a benign execution. The trusted hardware raises #VC when the CVM executes certain operations (e.g., vmmcall) as shown in the Animation below. The trusted hardware also stores the information about the operation that caused the #VC in the exit_reason register. The trusted guest Linux kernel in the CVM registers a handler for #VC. This handler reads the exit_reason and copies the necessary memory and register values into an unprotected shared memory region called the Guest Hypervisor Communication Block (GHCB) as shown in the Animation above. Then, the handler transfers the execution to the hypervisor. Once the hypervisor returns, the #VC handler copies data and register values back to the application context.

    -

    - - -wesee-benign

    -

    WeSee abuses the #VC handler in the kernel to compromise the CVM with 2 main observations: (a) the hypervisor can arbitrarily raise #VC to the CVM by injecting interrupt number 29 and (b) the hypervisor can control the value in the exit_reason register. We illustrate the hypervisor capabilities to compromise the security of the CVM with the example below.

    -

    Bypass Authentication with WeSee

    -

    Let’s consider an application that writes an application key key_app into rax and then uses the value in rax to authenticate a user who enters an input key (k_in).

    - - - -
    -
    -
    - -
    -
    rax = key_app
    -if rax == k_in:
    -   auth
    -else:
    -   fail
    -
    -
    -

    A malicious hypervisor without the right key can use WeSee to trick the victim application and authenticate successfully. Specifically, in the Code above, the hypervisor uses WeSee to change rax to a key that it controls (key_hyp). Then the application would inadvertently compare k_in with k_hyp to check if a user is authenticated. Because the hypervisor now controls both k_in and k_hyp it can authenticate successfully. - - - -wesee-example

    -

    In the Animation above, the hypervisor injects #VC with vmmcall as the exit_reason. This causes the #VC handler to first leak the value in the application’s rax (i.e., key_app) and then to write a hypervisor-controlled value into the application’s rax (i.e., key_hyp). Therefore, when the control returns back to the application, the value in rax is changed to key_hyp and the hypervisor authentication successfully.

    -

    WeSee Primitives

    -

    The hypervisor can set exit_reason register to any value of the 16 possible options. In WeSee we only use three: vmmcall, mmio_read, and mmio_write, and they are sufficient to construct powerful primitives.

    -

    Skip Instructions

    -

    First, we construct a primitive to skip arbitrary instructions while the kernel executes. We observe that the #VC handler increments the instruction pointer rip once the #VC is successfully handled. Therefore, by chaining #VCs we can skip any number of instructions. We ensure that the #VC execution does not have any undesirable side effects (e.g., change in register values). Therefore, we use exit_reason = vmmcall which does not have any undesirable side effects—it only reads rax and writes a hypervisor-controlled value to rax.

    -

    Read and Write to rax

    -

    Next, we build primitives to read and write to rax using exit_reason=vmmcall. As shown in our example attack, on vmmcall the #VC handler leaks the value of rax to the hypervisor. Then, it writes a hypervisor-controlled value into rax when the control returns. Furthermore, this does not have any other undesirable side effects. Therefore, we use the hypervisor to inject #VC with exit_reason=vmmcall to build our primitives.

    -

    Read Kernel Memory

    -

    To successfully read any kernel memory of the hypervisor’s choosing, the hypervisor needs 2 capabilities: (a) be able to control a pointer to kernel memory, and (b) this pointer is dereferenced and copied to the GHCB.

    -

    #VC handling for MMIO write: We observe that the hypervisor can gain these capabilities by abusing the mmio_write case in the #VC handler. Specifically, on a legitimate MMIO write from the application (e.g., mov [rdi], rbx), the hypervisor needs the value stored in the application’s context to write into the MMIO region (e.g., value in rbx). Therefore, the #VC handler first invokes a function get_ptr to get a pointer to the application’s register as shown in the Animation below. Note that, get_ptr returns the pointer in the rax register. Then, the #VC handler dereferences the value in the rax register and copies it into the GHCB. Thus, during normal operation, The hypervisor can use the value in the GHCB to write to the MMIO region. - - - -wesee-mmio_read

    -

    Next, we look at how the hypervisor controls the address for the memory read.

    -

    Attack using MMIO write handling: The hypervisor starts with the #VC exception with exit_reason=mmio_write as shown in the Animation below. Then, to gain control of the pointer, the hypervisor uses the read rax primitive when the get_ptr function returns. At this point, the hypervisor can write any address into the rax register. The #VC handler dereferences the rax as a pointer and writes the value into the GHCB leaking kernel memory values. For this attack to succeed, it is crucial for the hypervisor to eliminate undesirable side-effects (e.g., checks that lead to fail blocks). For a complete explanation check out our paper. - - - -wesee-mem_read

    -

    Write to Kernel Memory

    -

    Like the read memory primitive, the hypervisor can use exit_reason=mmio_read which reads a value from GHCB and writes it into the application’s context to arbitrarily write to kernel memory. We show the sequence of #VC injections and its effects in the Animation below.

    -

    - - -wesee-mem_write

    -

    Arbitrary Code Injection

    -

    To inject code to be executed in the kernel, we need to write to the .text section. By default, the kernel sets up its page tables such that the .text section is executable but not writable. To get around this constraint, we first use our read and write memory primitives to change the permissions in the kernel page tables. Specifically, we locate the page tables in kernel memory and then use the read memory primitive to perform a page table walk and the write memory primitive to edit the page permissions. Once all the permissions are changed, our target page is writable. -Finally, we can write shell code using a chain of write memory primitives to the target page.

    -

    Breaking into CVMs with WeSee

    -

    We demonstrate the expressive power of WeSee with three end-to-end case studies. -We leak kernel TLS session keys for NGINX with the arbitrary read. We use arbitrary write and code injection primitives to disable firewall rules and open a root shell. Next, we explain how we gain the root shell.

    -

    Gain a Root Shell

    -

    We demonstrate WeSee by injecting and executing arbitrary code in the guest Linux kernel. -The kernel exposes an API for kernel modules called call_usermodehelper. This API allows kernel modules to start a user space application from the kernel context. When invoked by a kernel module with an executable as an argument, it starts a process with the executable. Note that, this new process is started with root privileges. To attack a victim VM and gain a root shell, we can execute call_usermodehelper with

    -

    /bin/bash -c rm /tmp/t; mknod /tmp/t p; /bin/sh 0</tmp/t \| nc -ln 8001 1>/tmp/t

    -

    This command spawns a root shell that takes as input all network data from port 8001.

    -

    We inject our shell code into the Linux kernel’s function that receives and handles ICMP packets (icmp_rcv). To trigger this function, we send an ICMP packet to the SEV VM. When the shell code calls the call_usermodehelper API, it creates a new process with root privileges that provides a root shell that listens on port 8001. Then, to interact with the spawned shell we connect to the VM from the hypervisor using netcat. We inject a total of 2891 #VCs to perform the page walk and inject 392 bytes of shell code. See the video below for a demo!

    - -

    In summary, a malicious hypervisor can use WeSee to compromise SEV-SNP VMs and gain root access. For more details on our attacks check out our paper and code.

    -

    Affected Hardware and Software

    -

    All SEV-SNP processors are vulnerable to WeSee. There is a hotfix in the Linux kernel that mitigates our case study attacks. See FAQs for more information.

    -

    FAQs

    -
    - Q: Does WeSee affect non-confidential VMs that I have in the cloud? -
      -
    • No. WeSee assumes a malicious hypervisor to inject interrupts. For on-confidential cloud VMs, the hypervisor is implicitly trusted and will not attack the VMs. The hypervisor also prevents other malicious co-tenant VMs from injecting interrupts into the victim VM by checking and filtering interrupt injections.
    • -
    -
    -
    - Q: How do I protect myself from WeSee? -
      -
    • WeSee is tracked under one CVE: CVE-2024-25742
    • -
    • Upgrade the Linux kernel and use hardware features.
    • -
    • 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. WeSee 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? -
      -
    • WeSee uses interrupts, a notification mechanism, to compromise AMD SEV-SNP VMs making it an Ahoi attack.
    • -
    -
    -
    - Q: Why the name WeSee? -
      -
    • WeSee is a word-play on the VC exception.
    • -
    -
    -
    - Q: What was the response from hardware manufacturers? -
      -
    • AMD acknowledged the attacks but concluded that this is a vulnerability in the third-party software implementations of SEV-SNP.
    • -
    -
    -
    - 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 +WeSee +

        WeSee

        Using Malicious #VC Interrupts to Break AMD SEV-SNP
        (to appear at IEEE S&P 2024)

        How Does It Work?

        AMD SEV-SNP enables the creation of Confidential VMs (CVMs). This setting assumes a malicious hypervisor that cannot directly access the CVM’s memory. In a non-confidential setting, the hypervisor performs different operations (e.g., service hypercalls) that are important for the functionality of the applications. To support this functionality in the presence of a malicious hypervisor, AMD SEV introduces a new VMM Communication exception (#VC).

        #VC without an attacker: +Let’s first look at how #VC is handled during a benign execution. The trusted hardware raises #VC when the CVM executes certain operations (e.g., vmmcall) as shown in the Animation below. The trusted hardware also stores the information about the operation that caused the #VC in the exit_reason register. The trusted guest Linux kernel in the CVM registers a handler for #VC. This handler reads the exit_reason and copies the necessary memory and register values into an unprotected shared memory region called the Guest Hypervisor Communication Block (GHCB) as shown in the Animation above. Then, the handler transfers the execution to the hypervisor. Once the hypervisor returns, the #VC handler copies data and register values back to the application context.

        wesee-benign

        WeSee abuses the #VC handler in the kernel to compromise the CVM with 2 main observations: (a) the hypervisor can arbitrarily raise #VC to the CVM by injecting interrupt number 29 and (b) the hypervisor can control the value in the exit_reason register. We illustrate the hypervisor capabilities to compromise the security of the CVM with the example below.

        Bypass Authentication with WeSee

        Let’s consider an application that writes an application key key_app into rax and then uses the value in rax to authenticate a user who enters an input key (k_in).

        rax = key_app
        +if rax == k_in:
        +   auth
        +else:
        +   fail

        A malicious hypervisor without the right key can use WeSee to trick the victim application and authenticate successfully. Specifically, in the Code above, the hypervisor uses WeSee to change rax to a key that it controls (key_hyp). Then the application would inadvertently compare k_in with k_hyp to check if a user is authenticated. Because the hypervisor now controls both k_in and k_hyp it can authenticate successfully. +wesee-example

        In the Animation above, the hypervisor injects #VC with vmmcall as the exit_reason. This causes the #VC handler to first leak the value in the application’s rax (i.e., key_app) and then to write a hypervisor-controlled value into the application’s rax (i.e., key_hyp). Therefore, when the control returns back to the application, the value in rax is changed to key_hyp and the hypervisor authentication successfully.

        WeSee Primitives

        The hypervisor can set exit_reason register to any value of the 16 possible options. In WeSee we only use three: vmmcall, mmio_read, and mmio_write, and they are sufficient to construct powerful primitives.

        Skip Instructions

        First, we construct a primitive to skip arbitrary instructions while the kernel executes. We observe that the #VC handler increments the instruction pointer rip once the #VC is successfully handled. Therefore, by chaining #VCs we can skip any number of instructions. We ensure that the #VC execution does not have any undesirable side effects (e.g., change in register values). Therefore, we use exit_reason = vmmcall which does not have any undesirable side effects—it only reads rax and writes a hypervisor-controlled value to rax.

        Read and Write to rax

        Next, we build primitives to read and write to rax using exit_reason=vmmcall. As shown in our example attack, on vmmcall the #VC handler leaks the value of rax to the hypervisor. Then, it writes a hypervisor-controlled value into rax when the control returns. Furthermore, this does not have any other undesirable side effects. Therefore, we use the hypervisor to inject #VC with exit_reason=vmmcall to build our primitives.

        Read Kernel Memory

        To successfully read any kernel memory of the hypervisor’s choosing, the hypervisor needs 2 capabilities: (a) be able to control a pointer to kernel memory, and (b) this pointer is dereferenced and copied to the GHCB.

        #VC handling for MMIO write: We observe that the hypervisor can gain these capabilities by abusing the mmio_write case in the #VC handler. Specifically, on a legitimate MMIO write from the application (e.g., mov [rdi], rbx), the hypervisor needs the value stored in the application’s context to write into the MMIO region (e.g., value in rbx). Therefore, the #VC handler first invokes a function get_ptr to get a pointer to the application’s register as shown in the Animation below. Note that, get_ptr returns the pointer in the rax register. Then, the #VC handler dereferences the value in the rax register and copies it into the GHCB. Thus, during normal operation, The hypervisor can use the value in the GHCB to write to the MMIO region. +wesee-mmio_read

        Next, we look at how the hypervisor controls the address for the memory read.

        Attack using MMIO write handling: The hypervisor starts with the #VC exception with exit_reason=mmio_write as shown in the Animation below. Then, to gain control of the pointer, the hypervisor uses the read rax primitive when the get_ptr function returns. At this point, the hypervisor can write any address into the rax register. The #VC handler dereferences the rax as a pointer and writes the value into the GHCB leaking kernel memory values. For this attack to succeed, it is crucial for the hypervisor to eliminate undesirable side-effects (e.g., checks that lead to fail blocks). For a complete explanation check out our paper. +wesee-mem_read

        Write to Kernel Memory

        Like the read memory primitive, the hypervisor can use exit_reason=mmio_read which reads a value from GHCB and writes it into the application’s context to arbitrarily write to kernel memory. We show the sequence of #VC injections and its effects in the Animation below.

        wesee-mem_write

        Arbitrary Code Injection

        To inject code to be executed in the kernel, we need to write to the .text section. By default, the kernel sets up its page tables such that the .text section is executable but not writable. To get around this constraint, we first use our read and write memory primitives to change the permissions in the kernel page tables. Specifically, we locate the page tables in kernel memory and then use the read memory primitive to perform a page table walk and the write memory primitive to edit the page permissions. Once all the permissions are changed, our target page is writable. +Finally, we can write shell code using a chain of write memory primitives to the target page.

        Breaking into CVMs with WeSee

        We demonstrate the expressive power of WeSee with three end-to-end case studies. +We leak kernel TLS session keys for NGINX with the arbitrary read. We use arbitrary write and code injection primitives to disable firewall rules and open a root shell. Next, we explain how we gain the root shell.

        Gain a Root Shell

        We demonstrate WeSee by injecting and executing arbitrary code in the guest Linux kernel. +The kernel exposes an API for kernel modules called call_usermodehelper. This API allows kernel modules to start a user space application from the kernel context. When invoked by a kernel module with an executable as an argument, it starts a process with the executable. Note that, this new process is started with root privileges. To attack a victim VM and gain a root shell, we can execute call_usermodehelper with

        /bin/bash -c rm /tmp/t; mknod /tmp/t p; /bin/sh 0</tmp/t \| nc -ln 8001 1>/tmp/t

        This command spawns a root shell that takes as input all network data from port 8001.

        We inject our shell code into the Linux kernel’s function that receives and handles ICMP packets (icmp_rcv). To trigger this function, we send an ICMP packet to the SEV VM. When the shell code calls the call_usermodehelper API, it creates a new process with root privileges that provides a root shell that listens on port 8001. Then, to interact with the spawned shell we connect to the VM from the hypervisor using netcat. We inject a total of 2891 #VCs to perform the page walk and inject 392 bytes of shell code. See the video below for a demo!

        In summary, a malicious hypervisor can use WeSee to compromise SEV-SNP VMs and gain root access. For more details on our attacks check out our paper and code.

        Affected Hardware and Software

        All SEV-SNP processors are vulnerable to WeSee. There is a hotfix in the Linux kernel that mitigates our case study attacks. See FAQs for more information.

        FAQs

        Q: Does WeSee affect non-confidential VMs that I have in the cloud?
        • No. WeSee assumes a malicious hypervisor to inject interrupts. For on-confidential cloud VMs, the hypervisor is implicitly trusted and will not attack the VMs. The hypervisor also prevents other malicious co-tenant VMs from injecting interrupts into the victim VM by checking and filtering interrupt injections.
        Q: How do I protect myself from WeSee?
        • WeSee is tracked under one CVE: CVE-2024-25742
        • Upgrade the Linux kernel and use hardware features.
        • 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. WeSee 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?
        • WeSee uses interrupts, a notification mechanism, to compromise AMD SEV-SNP VMs making it an Ahoi attack.
        Q: Why the name WeSee?
        • WeSee is a word-play on the VC exception.
        Q: What was the response from hardware manufacturers?
        • AMD acknowledged the attacks but concluded that this is a vulnerability in the third-party software implementations of SEV-SNP.
        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 @@ -536,143 +32,6 @@

            FAQs

            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 have responsibly disclosed our findings to AMD on 26 October 2023. At the request of AMD, we extended the embargo till 4 April 2024.

        -

        CVE

        -

        WeSee is tracked under CVE-2024-25742.

        - - - - - -
        - -
        - - -
        -
        - - - - - - - - - - - - - - - - - - \ No newline at end of file +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 have responsibly disclosed our findings to AMD on 26 October 2023. At the request of AMD, we extended the embargo till 4 April 2024.

    CVE

    WeSee is tracked under CVE-2024-25742.

    \ No newline at end of file