Category Archives: Under our observation

Potential Risk of CVE, Under our observation

About CVE-2025-47365: Qualcomm integrated with automotive platform (7th Nov 2025)

Leave a comment
Published: 11/03/2025

Preface: GM’s Ultra Cruise system is supposed to be a more capable iteration of its Super Cruise ADAS that was first introduced in 2017.

To dig into the weeds a bit, the Ultra Cruise compute, which is about the size of two laptops stacked together, is made up of two Snapdragon SA8540P SoCs and one SA9000P AI accelerator to deliver low-latency control functions on 16-core CPUs and AI compute of more than 300 Tera operations per second for camera, radar and lidar processing.

Background: The Snapdragon Ride Platform accelerates the shift to software-defined vehicles by empowering developers to create AI-driven automated driving solutions. The system-on-chip, called Snapdragon Ride Platform, was developed for advanced driver assistance systems (ADAS) and automated driving. It’s one of a suite of cloud-connected platforms introduced by Qualcomm.

The Qualcomm Cloud AI 100/AIC100 family of products (including SA9000P – part of Snapdragon Ride) are PCIe adapter cards which contain a dedicated SoC ASIC for the purpose of efficiently running Artificial Intelligence (AI) Deep Learning inference workloads. They are AI accelerators.

Qualcomm’s Snapdragon SA8540P SoCs and SA9000P AI accelerator use the QNX Neutrino RTOS for safety-critical functions in automated driving systems.

Vulnerability details: Integer Overflow or Wraparound in Automotive Platform

Description – Memory corruption while processing large input data from a remote source via a communication interface.

Official announcement: Please refer to link for details –

https://docs.qualcomm.com/product/publicresources/securitybulletin/november-2025-bulletin.html

IoT, Under our observation

In-depth discussion of the basic knowledge of CAN BUS preventive control (30th Oct 2025)

Leave a comment

Preface: Is the CAN bus still in use? While the CAN protocol was originally designed for road vehicles and is still primarily used there, the vehicle bus format has found its way into aircraft, aerospace, and rail systems.

Background: CAN bus significantly reduces traditional cable connections by allowing multiple electronic control units (ECUs) to communicate over a single two-wire bus, which simplifies wiring, lowers costs, and reduces weight. This is a major advantage over traditional systems that require a separate, complex harness for each connection.

Manufacturer concerned about the security of externally accessible CAN (Controller Area Network) wires. Physical access to the CAN bus can indeed allow malicious actors to inject crafted messages, potentially controlling critical vehicle functions like remote start, door locks, or even braking systems.

Preventative Procedures Against CAN Injection via Physical Access: While physical access is hard to prevent entirely, several defensive measures can be implemented to mitigate the risk:

1. Network Segmentation – Description: Separate critical ECUs (Electronic Control Units) from non-critical ones using gateways.

Benefit: Limits access to sensitive systems even if an attacker gains access to one part of the network.

2. Message Authentication – Description: Use cryptographic methods to authenticate CAN messages.

Benefit: Prevents unauthorized messages from being accepted by ECUs.

Challenge: Standard CAN protocol lacks built-in support for encryption or authentication, so this requires custom implementation or use of CAN-FD with added security layers.

3. Intrusion Detection Systems (IDS) – Description: Monitor CAN traffic for anomalies or unauthorized message patterns.

Benefit: Detects and alerts on suspicious activity.

Example: Detecting messages with unexpected arbitration IDs or unusual frequency.

4. Physical Security – Description: Secure access to OBD-II ports and other external CAN access points.

Benefit: Prevents unauthorized physical connection to the CAN bus.

5. Rate Limiting and Filtering – Description: Limit the rate of messages and filter based on known-good IDs.

Benefit: Reduces the impact of flooding or spoofing attacks.

Perhaps an effective preventive measure is to install a filter. See the attached diagram for details.

Reference:

Similar vulnerabilities in the automotive industry can be found here. Please refer to the link – https://nvd.nist.gov/vuln/detail/CVE-2025-6785

Under our observation

About Bouncy Castle cryptography – CVE‐2025‐12194: The real fix is reachability fencing, which ensures timely resource disposal regardless of thread type. (28-10-2025)

Leave a comment

Published: 2025-10-24

Preface: The Australian government has utilized Bouncy Castle cryptography APIs. Specifically, the Australian Government’s AUSKey project, which was a system for securely accessing government online services, used the Bouncy Castle libraries as its basis for Java cryptography.

Bouncy Castle is a widely-used open-source cryptographic API available for Java and C#, developed and maintained by the Legion of the Bouncy Castle Inc., a registered Australian charitable organization. It is known for its FIPS-certified modules, which meet a recognized government standard for cryptographic modules.

Background: The objective of the Bouncy Castle cryptography project is to provide a comprehensive set of open-source APIs for Java and C# that implement cryptographic algorithms and protocols to build secure applications. It aims to offer a wide range of security features, including those for public key infrastructure, digital signatures, authentication, secure communication, and FIPS-certified cryptographic modules for applications requiring a high level of compliance. 

While the javax.crypto.Cipher class and the JCA/JCE frameworks provide the core for cryptographic operations in Java, the Bouncy Castle cryptography library is often needed for below reasons: 

Extended Algorithm Support: Bouncy Castle offers a broader range of cryptographic algorithms and modes compared to the default JCE providers, including advanced algorithms like elliptic curve cryptography (ECC) which may not be fully or natively supported by the standard JCE.

Implementation of Emerging Standards: Bouncy Castle frequently incorporates implementations of newer cryptographic standards and protocols before they are fully integrated into the standard JCE, allowing developers to utilize cutting-edge security features.

CVE details: Further issues have shown up in high-core environments with Java 21 and BC-FJA 2.1.1. It appears under very high loads the scheduling of the disposal thread is such that it only gets called rarely, or at least not soon enough. The issue has been fixed by introducing the use of reachability-fencing. This available in Java 9 and later, so Java 8 is still using the disposal daemon as before has been changed to reduce friction (synchronized has been introduced where some friction is still required). A new property has also been added “org.bouncycastle.native.cleanup_priority” which can be set to “min”, “normal”, or “high” (default “min”) in case disposal thread scheduling will be beneficial for Java 8 as well.

Official announcement: Please see the link for details –

https://www.tenable.com/cve/CVE-2025-12194

https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902025%E2%80%9012194

AI and ML, Potential Risk of CVE, Under our observation

Chypnosis on FPGAs – AMD is investigating whether on specific devices and components are affected and plans to provide updates as new findings emerge.(22nd Sep 2025)

Leave a comment

Preface: AMD uses FPGAs (Field-Programmable Gate Arrays) in High-Performance Computing (HPC) by offering accelerator cards and adaptive SoCs that allow users to program custom hardware for HPC workloads in fields like machine learning, data analytics, and scientific simulations.

AMD manufactures FPGA-based accelerator cards that enable users to program applications directly onto the FPGA, eliminating the lengthy card design process. These cards install as-is in servers, accelerating workloads in financial computing, machine learning, computational storage, and data analytics.

Background: The XADC is an integrated, on-chip block within certain AMD (formerly Xilinx) FPGAs that performs analog-to-digital conversion (ADC) and also includes on-chip sensors for voltage and temperature monitoring. The FPGA provides the programmable logic to process the digitized data from the XADC, use it for control, or access it through the FPGA’s interconnects like the Dynamic Reconfiguration Port (DRP) or JTAG interface.

Xilinx ADCs (XADCs), particularly flash ADCs, have disadvantages related to high power consumption, large physical size, and limited resolution due to the large number of comparators required for higher bit depth. Non-linearity can also introduce signal distortion and measurement errors, while the integration of ADCs directly into FPGAs may not be feasible for all applications due to the required external components.

Security Focus of an Academic Research Paper: Attacks on the Programmable Logic (PL) in AMD Artix™ 7 Series FPGA Devices.

Artix 7 FPGAs and Artix™ UltraScale+ difference – Key Differences at a Glance:

The main difference is that Artix™ UltraScale+ FPGAs are a newer, higher-performance family built on a 16nm FinFET process, offering improved power efficiency, higher transceiver speeds, and more advanced features like enhanced DSP blocks and hardened memory, while the Artix 7 FPGAs are older devices built on a 28nm process. UltraScale+ also features ASIC-class clocking, supports faster memory interfaces like LPDDR4x and DDR4, and includes advanced security features.

Vulnerability details: The academic research paper introducing the new approach demonstrates the attack on the programmable logic (PL) in AMD Artix™ 7-Series FPGA devices. It shows that the on-chip XADC-based voltage monitor is too slow to detect and/or execute a tamper response to clear memory contents. Furthermore, they show that detection circuits that have been developed to detect clock freezing2 are ineffective as well. In general, the attack can be applied on all ICs that do not have effective tamper responses to clear sensitive data in case of an undervoltage event.

Official announcement: Please see the link for details –

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

Potential Risk of CVE, Under our observation

CVE-2025-9999: About TCP-based client/server Networking feature of PcVue. (9th Sep 2025)

Leave a comment

Preface: PcVue is a well-known and highly regarded SCADA solution, renowned for its innovation and user-friendliness, despite facing competition from larger, more dominant SCADA vendors. While not the most popular solution, PcVue’s strengths in user configuration, advanced HMI functionality, and integration capabilities have solidified its position in the market.

Background: Key Objectives of PcVue SCADA

Supervisory Control and Monitoring: To offer a centralized platform for operators to monitor and control complex industrial processes and large-scale infrastructure in real-time.

Data Acquisition and Analysis: To collect, process, and convert raw data into actionable information, providing operators with relevant alerts, reports, and historical data for informed decision-making.

Vulnerability details: Some payload elements of the messages sent between two stations in a networking architecture are not properly checked on the receiving station allowing an attacker to execute unauthorized commands in the application.

Official announcement: Please see the link for details

https://www.pcvue.com/security/#SB2025-4

How to Prevent This:

Input Validation: Never trust client input. Use strict schemas (e.g., JSON Schema).

  • Command Execution Hardening:
  • Avoid os.system() or shell execution.
  • Use safe APIs like subprocess.run() with argument lists.

Authentication & Authorization: Ensure only authorized users can send control commands.

Web Application Firewall (WAF): Detect and block suspicious payloads.

AI and ML, IoT, Potential Risk of CVE, System, Under our observation

AMD releases details about Transient Scheduler Attack (TSA) – 9 Jul 2025

Leave a comment

Preface: CPU transient instructions refer to instructions that are speculatively executed by a processor’s out-of-order execution engine, but which may ultimately be discarded and not reflected in the processor’s architectural state. These instructions are executed based on predictions about control flow or data dependencies, and if the prediction is incorrect, the results of these transient instructions are discarded.

Background: Transient Scheduler Attacks (TSA) are new speculative side channel attacks related to the execution timing of instructions under specific microarchitectural conditions. In some cases, an attacker may be able to use this timing information to infer data from other contexts, resulting in information leakage.

Vulnerability details:

CVE-2024-36350 – A transient execution vulnerability in some AMD processors may allow an attacker to infer data from previous stores, potentially resulting in the leakage of privileged information.

CVE-2024-36357 – A transient execution vulnerability in some AMD processors may allow an attacker to infer data in the L1D cache, potentially resulting in the leakage of sensitive information across privileged boundaries.

CVE-2024-36348 – A transient execution vulnerability in some AMD processors may allow a user process to infer the control registers speculatively even if UMIP[3] feature is enabled, potentially resulting in information leakage.

CVE-2024-36349 – A transient execution vulnerability in some AMD processors may allow a user process to infer TSC_AUX even when such a read is disabled, potentially resulting in information leakage.

Official announcement: Please see the link for details –

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

Potential Risk of CVE, Under our observation

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

Leave a comment

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

AI and ML, Under our observation

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

Leave a comment

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.

Under our observation

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

Leave a comment

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

AI and ML, Under our observation

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

Leave a comment

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