diff --git a/index.xml b/index.xml index 36f5bf4..b33247b 100644 --- a/index.xml +++ b/index.xml @@ -1,4 +1,4 @@ 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 +ETH News Article: Knocking cloud security off its game (2024-04-04) +ETH News Article (German): Die Cloud-Sicherheit aus dem Konzept gebracht (2024-04-04) \ No newline at end of file diff --git a/media/index.html b/media/index.html index 0222e44..0e1e942 100644 --- a/media/index.html +++ b/media/index.html @@ -8,5 +8,6 @@

Media Coverage

Ahoi Attacks in the News:

+

Loading search index…

No recent searches

No results for "Query here"

Search by FlexSearch

Media Coverage

Ahoi Attacks in the News:

Edit this page on GitHub
Prev
Imprint
\ No newline at end of file diff --git a/search-index.json b/search-index.json index cae4386..c0b0e72 100644 --- a/search-index.json +++ b/search-index.json @@ -1 +1 @@ -[{"content":"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.\nToday, 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).\nTo 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).\nInterrupt 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.\nThe 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.\nSignal 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.\ndouble 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\u0026rsquo;s CVM.\nFor 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.\nThe 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.\nAnother 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.\n","date":"2024-04-04","id":0,"permalink":"/blog/ahoi-overview/","summary":"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.","tags":["heckler","wesee"],"title":"Overview of Ahoi Attacks"},{"content":"","date":"2024-04-01","id":1,"permalink":"/blog/","summary":"","tags":[],"title":"Ahoi Attacks Blog"},{"content":" Heckler Breaking Confidential VMs with Malicious Interrupts (to appear at USENIX Security 2024)\nPaper Source CVE 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.\nInt 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).\nSignals 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.\nIn 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.\nBreaking 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.\nSpecifically, 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.\nSudo 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.\nLike 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.\nIn 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.\nAffected Hardware and Software All Intel TDX and AMD SEV-SNP processors are vulnerable to Heckler. See our FAQs for more information.\nFAQ Q: Does this attack apply to other versions of SEV (e.g., SEV-ES)?\rWhile 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?\rNo. 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?\rNo. 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?\rHeckler is tracked under 2 CVEs: CVE-2024-25744 and CVE-2024-25743\nFor 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.\nFor 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.\nFor 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.\nQ: Is this a side-channel attack?\rNo. Heckler is not a side-channel attack. Q: What about other interrupt vectors?\rIn 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?\rHeckler abuses interrupts, a notification mechanism, to compromise CVMs making it an Ahoi attack. Q: Why the name Heckler?\rTo 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?\rIntel and AMD acknowledged the attacks but concluded that this is a vulnerability in the third-party software implementations of SEV-SNP and TDX. You find more information in their respective security advisories (Intel, AMD). Q: What was the response from cloud vendors?\rAzure 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.\nAWS thanked us for the disclosure and communicated the following:\nAWS 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.\nAuthors Benedict Schlüter Supraja Sridhara Mark Kuhne Andrin Bertschi Shweta Shinde 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.\nCVE Heckler is tracked under the following CVEs:\nCVE-2024-25744 CVE-2024-25743 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.\n","date":"2024-04-04","id":2,"permalink":"/heckler/","summary":"Heckler: Breaking Confidential VMs with Malicious Interrupts","tags":[],"title":"Heckler"},{"content":" WeSee Using Malicious #VC Interrupts to Break AMD SEV-SNP (to appear at IEEE S\u0026P 2024)\nPaper 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).\n#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.\nWeSee 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.\nBypass Authentication with WeSee Let\u0026rsquo;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).\nrax = key_app if rax == k_in: auth else: fail\rA 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. 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.\nWeSee 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.\nSkip 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.\nRead 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.\nRead 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.\n#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. Next, we look at how the hypervisor controls the address for the memory read.\nAttack 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. 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.\nArbitrary 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.\nBreaking 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.\nGain 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\n/bin/bash -c rm /tmp/t; mknod /tmp/t p; /bin/sh 0\u0026lt;/tmp/t \\| nc -ln 8001 1\u0026gt;/tmp/t\nThis command spawns a root shell that takes as input all network data from port 8001.\nWe 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!\nIn 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.\nAffected 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.\nFAQs Q: Does WeSee affect non-confidential VMs that I have in the cloud?\rNo. 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?\rWeSee 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?\rNo. WeSee is not a side-channel attack. Q: What about other interrupt vectors?\rIn 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?\rWeSee uses interrupts, a notification mechanism, to compromise AMD SEV-SNP VMs making it an Ahoi attack. Q: Why the name WeSee?\rWeSee is a word-play on the VC exception. Q: What was the response from hardware manufacturers?\rAMD acknowledged the attacks but concluded that this is a vulnerability in the third-party software implementations of SEV-SNP. You find more information in their security advisory. Q: What was the response from cloud vendors?\rAzure 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.\nAWS thanked us for the disclosure and communicated the following:\nAWS 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.\nAuthors Benedict Schlüter Supraja Sridhara Andrin Bertschi Shweta Shinde 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.\nCVE WeSee is tracked under CVE-2024-25742.\n","date":"2024-04-04","id":3,"permalink":"/wesee/","summary":"WeSee Using Malicious #VC Interrupts to Break AMD SEV-SNP (to appear at IEEE S\u0026P 2024)\nPaper Source CVE How Does It Work?","tags":[],"title":"WeSee"},{"content":"","date":"2024-04-04","id":4,"permalink":"/categories/","summary":"","tags":[],"title":"Categories"},{"content":"","date":"2024-04-04","id":5,"permalink":"/tags/heckler/","summary":"","tags":[],"title":"Heckler"},{"content":"","date":"2024-04-04","id":6,"permalink":"/categories/heckler/","summary":"","tags":[],"title":"Heckler"},{"content":"","date":"2024-04-04","id":7,"permalink":"/tags/","summary":"","tags":[],"title":"Tags"},{"content":"","date":"2024-04-04","id":8,"permalink":"/tags/wesee/","summary":"","tags":[],"title":"Wesee"},{"content":"","date":"2024-04-04","id":9,"permalink":"/categories/wesee/","summary":"","tags":[],"title":"Wesee"},{"content":"","date":"2023-09-07","id":10,"permalink":"/","summary":"","tags":[],"title":"Ahoi Attacks"},{"content":"","date":"0001-01-01","id":11,"permalink":"/contributors/","summary":"","tags":[],"title":"Contributors"},{"content":"Imprint Prof. Dr. Shweta Shinde CAB F 71.2 shweta.shinde@inf.ethz.ch Dep. Informatik Universitätstrasse 6 8092 Zürich Switzerland Disclaimer \u0026amp; Copyright Data Protection ","date":"0001-01-01","id":12,"permalink":"/imprint/","summary":"Imprint Prof. Dr. Shweta Shinde CAB F 71.2 shweta.shinde@inf.ethz.ch Dep. Informatik Universitätstrasse 6 8092 Zürich Switzerland Disclaimer \u0026amp; Copyright Data Protection ","tags":[],"title":"Imprint"},{"content":"Media Coverage Ahoi Attacks in the News:\nETH News Article (English): Knocking cloud security off its game\nETH News Article (German): Die Cloud-Sicherheit aus dem Konzept gebracht\nTech Xplore: Computer scientists discover gap in the latest security mechanisms used by some chips ","date":"0001-01-01","id":13,"permalink":"/media/","summary":"Media Coverage Ahoi Attacks in the News:\nETH News Article (English): Knocking cloud security off its game\nETH News Article (German): Die Cloud-Sicherheit aus dem Konzept gebracht","tags":[],"title":"Media Coverage"}] \ No newline at end of file +[{"content":"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.\nToday, 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).\nTo 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).\nInterrupt 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.\nThe 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.\nSignal 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.\ndouble 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\u0026rsquo;s CVM.\nFor 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.\nThe 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.\nAnother 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.\n","date":"2024-04-04","id":0,"permalink":"/blog/ahoi-overview/","summary":"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.","tags":["heckler","wesee"],"title":"Overview of Ahoi Attacks"},{"content":"","date":"2024-04-01","id":1,"permalink":"/blog/","summary":"","tags":[],"title":"Ahoi Attacks Blog"},{"content":" Heckler Breaking Confidential VMs with Malicious Interrupts (to appear at USENIX Security 2024)\nPaper Source CVE 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.\nInt 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).\nSignals 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.\nIn 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.\nBreaking 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.\nSpecifically, 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.\nSudo 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.\nLike 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.\nIn 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.\nAffected Hardware and Software All Intel TDX and AMD SEV-SNP processors are vulnerable to Heckler. See our FAQs for more information.\nFAQ Q: Does this attack apply to other versions of SEV (e.g., SEV-ES)?\rWhile 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?\rNo. 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?\rNo. 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?\rHeckler is tracked under 2 CVEs: CVE-2024-25744 and CVE-2024-25743\nFor 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.\nFor 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.\nFor 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.\nQ: Is this a side-channel attack?\rNo. Heckler is not a side-channel attack. Q: What about other interrupt vectors?\rIn 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?\rHeckler abuses interrupts, a notification mechanism, to compromise CVMs making it an Ahoi attack. Q: Why the name Heckler?\rTo 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?\rIntel and AMD acknowledged the attacks but concluded that this is a vulnerability in the third-party software implementations of SEV-SNP and TDX. You find more information in their respective security advisories (Intel, AMD). Q: What was the response from cloud vendors?\rAzure 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.\nAWS thanked us for the disclosure and communicated the following:\nAWS 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.\nAuthors Benedict Schlüter Supraja Sridhara Mark Kuhne Andrin Bertschi Shweta Shinde 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.\nCVE Heckler is tracked under the following CVEs:\nCVE-2024-25744 CVE-2024-25743 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.\n","date":"2024-04-04","id":2,"permalink":"/heckler/","summary":"Heckler: Breaking Confidential VMs with Malicious Interrupts","tags":[],"title":"Heckler"},{"content":" WeSee Using Malicious #VC Interrupts to Break AMD SEV-SNP (to appear at IEEE S\u0026P 2024)\nPaper 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).\n#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.\nWeSee 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.\nBypass Authentication with WeSee Let\u0026rsquo;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).\nrax = key_app if rax == k_in: auth else: fail\rA 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. 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.\nWeSee 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.\nSkip 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.\nRead 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.\nRead 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.\n#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. Next, we look at how the hypervisor controls the address for the memory read.\nAttack 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. 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.\nArbitrary 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.\nBreaking 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.\nGain 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\n/bin/bash -c rm /tmp/t; mknod /tmp/t p; /bin/sh 0\u0026lt;/tmp/t \\| nc -ln 8001 1\u0026gt;/tmp/t\nThis command spawns a root shell that takes as input all network data from port 8001.\nWe 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!\nIn 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.\nAffected 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.\nFAQs Q: Does WeSee affect non-confidential VMs that I have in the cloud?\rNo. 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?\rWeSee 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?\rNo. WeSee is not a side-channel attack. Q: What about other interrupt vectors?\rIn 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?\rWeSee uses interrupts, a notification mechanism, to compromise AMD SEV-SNP VMs making it an Ahoi attack. Q: Why the name WeSee?\rWeSee is a word-play on the VC exception. Q: What was the response from hardware manufacturers?\rAMD acknowledged the attacks but concluded that this is a vulnerability in the third-party software implementations of SEV-SNP. You find more information in their security advisory. Q: What was the response from cloud vendors?\rAzure 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.\nAWS thanked us for the disclosure and communicated the following:\nAWS 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.\nAuthors Benedict Schlüter Supraja Sridhara Andrin Bertschi Shweta Shinde 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.\nCVE WeSee is tracked under CVE-2024-25742.\n","date":"2024-04-04","id":3,"permalink":"/wesee/","summary":"WeSee Using Malicious #VC Interrupts to Break AMD SEV-SNP (to appear at IEEE S\u0026P 2024)\nPaper Source CVE How Does It Work?","tags":[],"title":"WeSee"},{"content":"","date":"2024-04-04","id":4,"permalink":"/categories/","summary":"","tags":[],"title":"Categories"},{"content":"","date":"2024-04-04","id":5,"permalink":"/tags/heckler/","summary":"","tags":[],"title":"Heckler"},{"content":"","date":"2024-04-04","id":6,"permalink":"/categories/heckler/","summary":"","tags":[],"title":"Heckler"},{"content":"","date":"2024-04-04","id":7,"permalink":"/tags/","summary":"","tags":[],"title":"Tags"},{"content":"","date":"2024-04-04","id":8,"permalink":"/tags/wesee/","summary":"","tags":[],"title":"Wesee"},{"content":"","date":"2024-04-04","id":9,"permalink":"/categories/wesee/","summary":"","tags":[],"title":"Wesee"},{"content":"","date":"2023-09-07","id":10,"permalink":"/","summary":"","tags":[],"title":"Ahoi Attacks"},{"content":"","date":"0001-01-01","id":11,"permalink":"/contributors/","summary":"","tags":[],"title":"Contributors"},{"content":"Imprint Prof. Dr. Shweta Shinde CAB F 71.2 shweta.shinde@inf.ethz.ch Dep. Informatik Universitätstrasse 6 8092 Zürich Switzerland Disclaimer \u0026amp; Copyright Data Protection ","date":"0001-01-01","id":12,"permalink":"/imprint/","summary":"Imprint Prof. Dr. Shweta Shinde CAB F 71.2 shweta.shinde@inf.ethz.ch Dep. Informatik Universitätstrasse 6 8092 Zürich Switzerland Disclaimer \u0026amp; Copyright Data Protection ","tags":[],"title":"Imprint"},{"content":"Media Coverage Ahoi Attacks in the News:\nETH News Article: Knocking cloud security off its game (2024-04-04)\nETH News Article (German): Die Cloud-Sicherheit aus dem Konzept gebracht (2024-04-04)\nTech Xplore: Computer scientists discover gap in the latest security mechanisms used by some chips (2024-04-04)\nInside IT (German): ETH entdeckt Sicherheitslücke, die grosse Cloud-Anbieter betrifft (2024-04-05)\nLinux Security: Hacked VMs Reveal New Attack Risks (2024-04-08)\nSecurity Week: Confidential VMs Hacked via New Ahoi Attacks (2024-04-08)\n","date":"0001-01-01","id":13,"permalink":"/media/","summary":"Media Coverage Ahoi Attacks in the News:\nETH News Article: Knocking cloud security off its game (2024-04-04)\nETH News Article (German): Die Cloud-Sicherheit aus dem Konzept gebracht (2024-04-04)","tags":[],"title":"Media Coverage"}] \ No newline at end of file