Category Archives: Under our observation

Cache-based Side-Channel Attack Against SEV (4th Jun 2025)

Originally posted by AMD 3rd Feb 2025

2025-02-17 – Updated Acknowledgement

2025-06-03 Update:A subsequent report of the same attacks was received from researchers at Graz University of Technology.

Preface: FIPS 186-5 removes DSA as an approved digital signature algorithm “due to a lack of use by industry and based on academic analyses that observed that implementations of DSA may be vulnerable to attacks if domain parameters are not properly generated.

February 3, 2023 – NIST published Federal Information Processing Standard (FIPS) 186-5, Digital Signature Standard (DSS), along with NIST Special Publication (SP) 800-186, Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters.  

Background: The SEV feature relies on elliptic-curve cryptography for its secure key generation, which runs when a VM is launched. The VM initiates the elliptic-curve algorithm by providing points along its NIST (National Institute of Standards and Technology) curve and relaying the data based on the private key of the machine.

Vulnerability details: AMD has received a report from researchers at National Taiwan University detailing cache-based side-channel attacks against Secure Encrypted Virtualization (SEV).

Remedy: AMD recommends software developers employ existing best practices for prime and probe attacks (including constant-time algorithms) and avoid secret-dependent data accesses where appropriate.  AMD also recommends following previously published guidance regarding Spectre type attacks (refer to the link in the reference section below), as it believes the previous guidance remains applicable to mitigate these vulnerabilities.

Supplement: The lack of authentication in the memory encryption is one major drawback of the Secure Memory Encryption (SME) design, which has been demonstrated in fault injection attacks. SEV inherits this security issue. Therefore, a malicious hypervisor may alter the ciphertext of the encrypted memory without triggering faults in the guest VM.

Office announcement: Please refer to the link for details –

https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3010.html

When artificial intelligence encounters a geomagnetic storm (26-05-2025)

Preface: About fifteen years ago, extreme climate sounded the alarm for humanity. But we haven’t woken up yet. As we enter 2025, extreme weather is raging. Are we awake now?

Background: A coronal mass ejection (CME) can induce a geomagnetic storm when it interacts with Earth’s magnetosphere. CMEs are large clouds of plasma and magnetic fields ejected from the Sun, and when they hit Earth, they can disrupt the Earth’s magnetosphere, leading to temporary disturbances and geomagnetic storms.

Geomagnetic storms create geomagnetically induced currents (GICs). Geomagnetic storms, which are disturbances of Earth’s magnetic field caused by space weather events like coronal mass ejections (CMEs), induce rapid changes in the magnetic field. These changes, in turn, create electric fields that drive GICs to flow through conductive paths on Earth’s surface, such as power grids, pipelines, and other infrastructure.

How much electricity does a supercomputer used for artificial intelligence consume?

A single modern AI GPU can consume up to 700 watts of power. A typical supercomputer, especially those used for AI training, can consume significantly more power, with some examples exceeding 4 megawatts (4,000,000 watts). This high power consumption is largely due to the large number of powerful GPUs and other specialized hardware needed for these complex computations.

How does artificial intelligence think about this problem?

Building a supercomputer facility underground with its own dedicated power supply does significantly reduce—but not entirely eliminate—the risks from geomagnetic storms. Here’s a breakdown:

1.Underground Location:

-Provides natural shielding from fluctuating magnetic fields.

-Reduces exposure to induced currents in long conductors.

2.Dedicated Power Supply:

-If it’s isolated from the main power grid (e.g., using local generators, batteries, or renewables), it avoids GICs that typically enter through long transmission lines.

Shorter internal cabling means less potential for induced voltages.

3.Shielded Infrastructure:

-If the facility uses shielded transformers, GIC-blocking devices, and grounding systems, it can further mitigate risks.

End.

Part 1: Spectre-v2 Domain Isolation, does it fight against variants? (19-05-2025)

Preface: In computer architecture, a branch predictor is a digital circuit that tries to guess which way a branch will go before this is known definitively.

Background: Although the Spectre v2 vulnerability has been protected by domain isolation technologies such as IBPB, eIBRS and BHI_NO, which prevent attackers from training the indirect branch predictor with their own code, the VUSec security research team found that as long as the attacker allows the code to train itself (that is, training and speculative execution occur in the same privileged domain), the Spectre v2 attack can be re-implemented.

Modern CPUs use branch predictors to guess the target of indirect branches (like function pointers or virtual calls) to keep the pipeline full and improve performance. These predictors are part of the speculative execution engine.

How Attackers Use Their Own Code?

1. Attackers Use Their Own Code

2.Triggering Misprediction:

– When the victim code runs, the CPU may speculatively execute based on the attacker’s training.

– If the attacker has set things up correctly, the CPU speculatively executes code paths that leak sensitive data (e.g., via cache timing).

3.The attacker then uses cache timing attacks (like Flush+Reload or Prime+Probe) to infer what was speculatively executed, revealing secrets.

White paper: Researchers from VU Amsterdam have shared with AMD a paper exploring the effectiveness of domain isolation against Spectre-v2 type attacks.

AMD believes the techniques described by the researchers are not applicable to AMD products.

For more details, please refer to link – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7034.html

Privilege Desynchronization: Cross-Privilege Spectre Attacks with Branch Privilege Injection – Part 2 (14-05-2025)

Preface: Before reading the detailed information, it is recommended to read Part 1 first.

Privilege Desynchronization: Cross-Privilege Spectre Attacks with Branch Privilege Injection (Part 1)  –

http://www.antihackingonline.com/under-our-observation/privilege-desynchronization-cross-privilege-spectre-attacks-with-branch-privilege-injection-14-05-2025/

Technical details: It is to ensure the serialization of memory access. The internal operation is to add some delays in a series of memory accesses to ensure that the memory access after this instruction occurs after the memory access before this instruction is completed (no overlap occurs).

Performs a serializing operation on all load-from-memory instructions that were issued prior the LFENCE instruction. Specifically, LFENCE does not execute until all prior instructions have completed locally, and no later instruction begins execution until LFENCE completes.

AMD’s AutoIBRS (Automatic Indirect Branch Restricted Speculation) is designed to mitigate timing-based attacks, such as Spectre. AutoIBRS helps avoid the performance overhead associated with LFENCE by automatically restricting speculative execution of indirect branches. This mechanism reduces the need for frequent LFENCE instructions, thereby minimizing delays while still protecting against timing vulnerabilities.

Cyber security focus provided by ETH Zurich: Researchers from ETH Zurich have provided AMD with a paper titled “Privilege Desynchronization: Cross-Privilege Spectre Attacks with Branch Privilege Injection.”
AMD reviewed the paper and believes that this vulnerability does not impact AMD CPUs. 

If supported by the processor, operating systems enable eIBRS or AutoIBRS to mitigate cross-privilege BTI attacks. These mitigations need to keep track of the privilege domain of branch instructions to work correctly, which is non-trivial due to the highly complex and asynchronous nature of branch prediction. For example, previous work has shown that branch predictions are updated before branches retire, and in certain cases even before they are decoded. Our first challenge revolves around analyzing the behavior of restricted branch prediction under race conditions.

Official announcement: Researchers from ETH Zurich have provided AMD with a paper titled “Privilege Desynchronization: Cross-Privilege Spectre Attacks with Branch Privilege Injection.”
AMD reviewed the paper and believes that this vulnerability does not impact AMD CPUs. 

Please see the link for details – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7030.html

Privilege Desynchronization: Cross-Privilege Spectre Attacks with Branch Privilege Injection (14-05-2025)

Preface: Enhanced IBRS (eIBRS) and Automatic IBRS (AutoIBRS) are features designed to mitigate the Spectre V2 vulnerability, which affects speculative execution in CPUs.

Background: AutoIBRS is a similar feature introduced by AMD in their Zen 4 processors. It automatically manages IBRS mitigation resources across privilege level transitions, offering better performance compared to Retpoline. This feature is particularly beneficial for AMD’s Ryzen 7000 and EPYC 9004 series processors.

AMD EPYC 9004 series processors are designed for data centers and high-performance computing (HPC) environments. They offer features like up to 96 “Zen 4” cores, 12 channels of DDR5 memory, and PCIe Gen5 support.

Cyber security focus provided by ETH Zurich: Researchers from ETH Zurich have provided AMD with a paper titled “Privilege Desynchronization: Cross-Privilege Spectre Attacks with Branch Privilege Injection.”
AMD reviewed the paper and believes that this vulnerability does not impact AMD CPUs. 

If supported by the processor, operating systems enable eIBRS or AutoIBRS to mitigate cross-privilege BTI attacks. These mitigations need to keep track of the privilege domain of branch instructions to work correctly, which is non-trivial due to the highly complex and asynchronous nature of branch prediction. For example, previous work has shown that branch predictions are updated before branches retire, and in certain cases even before they are decoded. Our first challenge revolves around analyzing the behavior of restricted branch prediction under race conditions.

Official announcement: Researchers from ETH Zurich have provided AMD with a paper titled “Privilege Desynchronization: Cross-Privilege Spectre Attacks with Branch Privilege Injection.”
AMD reviewed the paper and believes that this vulnerability does not impact AMD CPUs. 

Please see the link for details – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7030.html

CVE-2025-30217: SQL injection on Frappe web application framework (27th Mar 2025)

Preface: The Frappe Framework comes equipped with a wide range of built-in tools and features that accelerate the development process. Developers can leverage ready-to-use modules, templates, and components to create applications quickly.

Background: Frappe Framework – A full-stack web application framework written in Python and Javascript. The framework provides a robust foundation for building web applications, including a database abstraction layer, user authentication and a REST API. Frappe UI: A Vue-based UI library to provide a modern user interface.

Remark: Frappe UI: A Vue-based UI library to provide a modern user interface. The Frappe UI library provides a variety of components that can be used to build single-page applications on top of the Frappe Framework.

Vulnerability details: SQL injection could be achieved via a specially crafted request, which could allow malicious person to gain access to sensitive information.

Ref: The Frappe web application framework can be vulnerable to SQL injection attacks if it constructs SQL commands using externally-influenced input from an upstream component without properly neutralizing special elements.

Official announcement: Please refer to the link for details – https://nvd.nist.gov/vuln/detail/CVE-2025-30217

AMD urged software developers to implement best practices to avoid secret-dependent data accesses or control flows. (28-04-2024)

Originally published on April 26, 2024.

Preface: (Level 3 cache) A memory bank built onto the motherboard or within the CPU module. The L3 cache feeds the L2 cache, and its memory is typically slower than the L2 memory, but faster than main memory.

Background: The last-level cache (LLC) is the last chance for memory accesses from the processor to avoid the costly latency of going to main memory. Level 3 (L3) represents the Last Level Cache (LLC) in the example above, and is the last (and slowest) stop within the cache hierarchy before the system must endure the long trek out to Main Memory.

The last-level cache (LLC) is one of the most dangerous shared resources since it is shared by all of the cores in a processor package, yet it allows fine-grained, high-bandwidth, low-noise cross-core attacks.

The cache memory divides into three levels:

L1 cache – fastest, but smallest, data and instructions

L2 cache – slower, but bigger, data-only

L3 cache – slowest, but biggest, data-only

Vulnerability detail: Cache side channel attacks work by monitoring security-critical operations such as AES T table entries or modular exponentiation or multiplication or memory accesses. The attacker is then able to derive the encryption key by recovering the key based on the accesses made (or not made) by the victim.

Official announcement: Please refer to the link for details –

https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7019.html

To be new or it was former: Rowhammer Attacks on AMD Zen-Based Platforms. So called ZenHammer (25-03-2024)

Preface: It is possible to trigger Rowhammer bit flips on DDR4 devices on AMD Zen 2 and Zen 3 systems despite deployed TRR mitigations, said researchers at ETH Zurich.

Background: When high-energy charged particles pass through the crystal lattice of a silicon wafer, their charges can interfere with the electrons within the lattice itself and provide energy. If the lattice is moved closer together within the wafer, this disturbed electron trajectory can create a temporary highly conductive path that did not exist before. The effect of this trace is similar to running a very thin wire across the wafer in random directions. If the particle’s path crosses a feature within the die, such as a floating MOSFET gate or an NMOS DRAM cell, the result may be a flipped bit.

Vulnerability details: On February 26, 2024, AMD received new research related to an industry-wide DRAM issue documented in “ZENHAMMER: Rowhammering Attacks on AMD Zen-based Platforms” from researchers at ETH Zurich. The research demonstrates performing Rowhammer attacks on DDR4 and DDR5 memory using AMD “Zen” platforms. Given the history around Rowhammer, the researchers do not consider these rowhammering attacks to be a new issue.

Mitigation: Please see the following official announcement for details – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7021.html

CVE-2023-27997 Lack of detail, but can we find hints? (12th June 2023)

Preface: If you need to push audio/video traffic over the tunnel DTLS can be a huge performance improvement.

Background: Preferred DTLS Tunnel
If enabled, FortiClient uses DTLS if it is enabled on the FortiGate and tunnel establishment is successful. If not enabled on the FortiGate or tunnel establishment does not succeed, TLS is used. DTLS tunnel uses UDP instead of TCP and can increase throughput over VPN.
When disabled, FortiClient uses TLS, even if DTLS is enabled on FortiGate.

Vulnerability details: Fortinet has released firmware updates their pre-authentication remote code execution vulnerability in SSL VPN devices.
The security fixes were released on Friday in FortiOS firmware versions 6.0.17, 6.2.15, 6.4.13, 7.0.12, and 7.2.5.

Details of the vulnerability displayed above: Please refer to the bleepingcomputer – https://www.bleepingcomputer.com/news/security/fortinet-fixes-critical-rce-flaw-in-fortigate-ssl-vpn-devices-patch-now/

My observation: Since no details provided by vendor. So, my assumptions can be find in attached diagram.

About CVE-2023-29345 and CVE-2023-33143, Microsoft released Security Updated of the Chromium project (6th June 2023)

Preface: Windows has traditionally run on machines that are powered by x86 / x64 processors. Windows 11 adds the capability to run unmodified x64 Windows apps on Arm devices! This capability to run x86 & x64 apps on Arm devices gives end-users confidence that the majority of their existing apps & tools will run well even on new Arm-powered devices. For the best of result, it can exploit Arm-native Windows apps theoretically, as a result, developers cope with trend , thus built or port Arm-native Windows apps.


Background: Codenamed “Anaheim”, on December 6, 2018, Microsoft announced its intent to base Edge on the Chromium source code, using the same browser engine as Google Chrome but with enhancements developed by Microsoft. The new Microsoft Edge (Chromium) is built on the same underlying technology as Google Chrome. During the Ignite 2021 conference, Microsoft revealed plans to align the codebase of the Edge browser on all supported platforms.


Vulnerability details:
CVE-2023-29345 Microsoft Edge Remote Code Execution – A vulnerability was found in Microsoft Edge (Web Browser) (version unknown).
CVE-2023-33143 – Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability
For details, please refer to the link – https://learn.microsoft.com/en-us/deployedge/microsoft-edge-relnotes-security