Category Archives: System

System

IEC 62351 is the official security extension for IEC 60870-5-104. How OpenSSL assists. (29th Aug 2025)

Leave a comment

Preface: Two of the most often used protocols in SCADA networks are Modbus and IEC 60870 – 5. A communication protocol is a collection of rules that enable two or more networked entities to interact with each other. Both the transmitter and the recipient of the information must agree on the protocol.

Background: In IEC 60870-5-104 (IEC-104) specifications, the Protocol Control Information (PCI) sequence number is a 15-bit value found in the Control field of frames to manage ordered information transfer. There are two types of sequence numbers: the Send Sequence Number (SSN), which the sending station increments for each I-frame sent, and the Receive Sequence Number (RSN), which acknowledges the last SSN received. The RSN effectively acknowledges all frames from the previously received SSN up to the current one

1.If a station sends an I-frame with SSN 0, it would then set the RSN to 1 in that frame. 

2.If the receiving station receives this frame and then sends its own frame, the RSN in that outgoing frame would be 2, acknowledging both the frame with SSN 0 and the subsequent frames.

Cyber-security focus: The IEC 60870-5-104 protocol, while widely used in industrial control systems, lacks built-in authentication and encryption, which makes it susceptible to several types of attacks, including: IP spoofing , Session hijacking, Replay attacks and Unauthorized command injection.

How to Mitigate?

To secure IEC 60870-5-104, consider the following industry best practices:

1. Use IEC 62351 – This standard adds TLS encryption, authentication, and integrity checks to IEC protocols.

    It’s the official security extension for IEC 60870-5-104.

2. Network Segmentation – Isolate control networks from corporate or public networks.

    Use firewalls and VLANs to restrict access.

3. IP Whitelisting and Port Hardening – Only allow known IP addresses to connect to the IEC server.

    Use non-default ports and monitor for unusual traffic.

4. Deep Packet Inspection (DPI) – Use industrial firewalls or intrusion detection systems (IDS) that understand IEC 104 traffic.

    Detect anomalies in SSN/RSN behavior or unauthorized commands.

5. Secure Boot and Firmware Validation – Ensure that devices running IEC 104 are not compromised at the firmware level.

End of topic.

AI and ML, System

The whole world is paying attention to Nvidia, but supercomputers using AMD are the super ones! (July 28, 2025)

Leave a comment

Preface: The El Capitan system at the Lawrence Livermore National Laboratory, California, USA remains the No. 1 system on the TOP500. The HPE Cray EX255a system was measured with 1.742 Exaflop/s on the HPL benchmark. El Capitan has 11,039,616 cores and is based on AMD 4th generation EPYC™ processors with 24 cores at 1.8 GHz and AMD Instinct™ MI300A accelerators. It uses the HPE Slingshot interconnect for data transfer and achieves an energy efficiency of 58.9 Gigaflops/watt. The system also achieved 17.41 Petaflop/s on the HPCG benchmark which makes it the new leader on this ranking as well. June 2025

Background: Does El Capitan Use Docker or Kubernetes? El Capitan does not use Docker directly, but it does use Kubernetes—specifically:

Kubernetes is deployed on Rabbit and worker nodes. It is part of a stateless orchestration layer integrated with the Tri-Lab Operating System Stack (TOSS).

Kubernetes is used alongside Flux (the resource manager) and Rabbit (the near-node storage system) to manage complex workflows.

Why Kubernetes Instead of Docker Alone?

While Docker is lightweight and flexible, Kubernetes offers orchestration, which is critical for:

  • Managing thousands of concurrent jobs.
  • Coordinating data movement and storage across Rabbit nodes.
  • Supporting AI/ML workflows and in-situ analysis.

But Kubernetes has a larger memory and CPU footprint than Docker alone.

Technical details: HPE Cray Operating System (COS) is a specialized version of SUSE Linux Enterprise Server designed for high-performance computing, rather than being a variant of Red Hat Enterprise Linux. It’s built to run large, complex applications at scale and enhance application efficiency, reliability, management, and data access. While COS leverages SUSE Linux, it incorporates features tailored for supercomputing environments, such as enhanced memory sharing, power monitoring, and advanced kernel debugging.

What Does Cray Modify?
Cray (now part of HPE) primarily modifies:
-The Linux kernel for performance tuning, scalability, and hardware support
-Adds HPC-specific enhancements, such as:
Optimized scheduling
NUMA-aware memory management
High-speed interconnect support (e.g., Slingshot)
Enhanced I/O and storage stack
-Integrates with Cray Shasta architecture and Slingshot interconnect

These modifications are layered on top of SUSE Linux, meaning the base OS remains familiar and enterprise-grade, but is tailored for supercomputing.

End.

Our world is full of challenges and hardships. But you must be happy every day!

AI and ML, System

Nvidia security focus – Rowhammer attack potential risk – July 2025 (11th July 2025)

Leave a comment

Preface: The Rowhammer effect, a hardware vulnerability in DRAM chips, was first publicly presented and analyzed in June 2014 at the International Symposium on Computer Architecture (ISCA). This research, conducted by Yoongu Kim et al., demonstrated that repeatedly accessing a specific row in a DRAM chip can cause bit flips in nearby rows, potentially leading to security breaches.

Background: Nvidia has shifted from “copy on flip” to asynchronous copy mechanisms in their GPU architecture, particularly with the Ampere architecture and later. This change allows for more efficient handling of data transfers between memory and the GPU, reducing latency and improving overall performance, especially in scenarios with high frame rates or complex computations.

When System-Level ECC is enabled, it prevents attackers from successfully executing Rowhammer attacks by ensuring memory integrity. The memory controller detects and corrects bit flips, making it nearly impossible for an attacker to exploit them for privilege escalation or data corruption.

Technical details: Modern DRAMs, including the ones used by NVIDIA, are potentially susceptible to Rowhammer. The now decade-old Rowhammer problem has been well known for CPU memories (e.g., DDR, LPDDR). Recently, researchers at the University of Toronto demonstrated a successful Rowhammer exploitation on a NVIDIA A6000 GPU with GDDR6 memory where System-Level ECC was not enabled. In the same paper, the researchers showed that enabling System-Level ECC mitigates the Rowhammer problem. 

Official announcement: Technical details: see link – https://nvidia.custhelp.com/app/answers/detail/a_id/5671

Potential Risk of CVE, System

CVE-2025-32462 – Local Privilege Escalation via chroot option (10th July 2025)

Leave a comment

Preface: Using LDAP to manage sudoers rules is becoming a more common practice, particularly in larger organizations. It offers several advantages over traditional methods of storing sudoers in a local file, including simplified management, improved scalability, and enhanced security.

Background:

Best Practices for Using sudo.

  • Avoid Logging in as Root: Use sudo instead of su to minimize security risks.
  • Grant Minimal Permissions: Assign only the necessary privileges to prevent unauthorized access.
  • Monitor sudo Usage: Check logs for suspicious activity

This helps to minimize security risks associated with elevated privileges.

* Specific commands: Instead of ALL=(ALL:ALL), grant access to specific commands only. For example, jane ALL=(ALL:ALL) /usr/bin/apt update, /usr/bin/apt upgrade

Vulnerability details: Sudo before 1.9.17p1, when used with a sudoers file that specifies a host that is neither the current host nor ALL, allows listed users to execute commands on unintended machines.

This vulnerability occurs when a sudoers file specifies a host that is neither the current host nor ALL. In such cases, sudo may incorrectly allow listed users to execute commands on unintended machines.

This is a configuration-based logic flaw rather than a memory corruption or privilege escalation bug. It does not involve CHROOT directly, but rather the host-specific rule matching in sudoers.

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

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

AI and ML, Potential Risk of CVE, System

AMD Fixed CVE-2024-21969 (23rd June 2025)

Leave a comment

CVE-2024-21969: Whispering Pixels: Exploiting Uninitialized Register Accesses in Modern GPUs.

Preface: How to Enable Secure GPU Mode (Register Clearing)

  • This mode is supported on the following AMD GPUs:
  • Radeon RX 5000, 6000, 7000, 9000 series
  • Radeon PRO W5000, W6000, W7000 series
  • Radeon AI PRO 9000 series
  • Radeon VII, RX Vega
  • Instinct MI210, MI250, MI300X, etc.

Background: The proliferation of graphics processing units (GPUs) has brought unprecedented computing power.

Multiple register-based vulnerabilities found across different GPU implementations.

So-called whisper pixels. The vulnerability poses unique challenges to an adversary due to opaque scheduling and register remapping algorithms present in the GPU firmware, complicating the reconstruction of leaked data.

GPU Programming: An application has to use vendor- provided libraries in order to translate a shader from its high-level source code to an architecture-dependent binary code. Vendors provide these libraries for a variety of high-level languages.

Vulnerability details: Improper clearing of GPU registers could allow a malicious shader to read left-over pixel data leading to loss of confidentiality.

Mitigation (13th Aug 2024): AMD plans to create a new operating mode designed to prevent processes from running in parallel on the GPU, and to clear registers between processes on supported products.

Last Updated Date (23-06-2025): AMD has created a new operating mode designed to prevent processes from running in parallel on the GPU, and to clear registers between processes on supported products.  This mode is not enabled by default and needs to be set by an administrator. AMD expects performance impacts if the new mode is enabled in environments where multiple processes would have been running simultaneously on the GPU.  The performance impact will be related to the number of processes that would have been running in parallel.  Additionally, a lesser performance impact may arise due to the additional clearing of registers between processes.

Instructions for enabling the new mode can be found in the relevant release notes and/or product documentation.

AMD started rolling out mitigation options beginning in May 2024 through applicable driver updates.

Official announcement: Please refer to the website for details – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-6013.html

AI and ML, Potential Risk of CVE, System

CVE-2025-23252 – NVIDIA has released a software update for NVIDIA® NVDebug tool to address the security issue.(18-06-2025)

Leave a comment

Preface: The NVdebug tool, used for NVIDIA GPU debugging, relies on the NVIDIA Data Center GPU Manager (DCGM) library. Specifically, it utilizes DCGM version 2.2.x or later. DCGM is a suite of tools for managing and monitoring NVIDIA GPUs in data center and cluster environments.

Background: The NV Debug Tool is part of the NVIDIA Nsight Systems and Nsight Graphics development tools. These tools are designed for debugging and profiling GPU-accelerated applications, including those using CUDA and other graphics APIs. It’s useful for debugging both CPU and GPU code, especially for CUDA applications.

Nsight Systems can collect logs for both Nsight Compute and Nsight Graphics. Nsight Systems is a system-wide performance analysis tool, while Nsight Compute focuses on kernel-level profiling and Nsight Graphics specializes in graphics application debugging and profiling. Nsight Systems can gather data that is relevant to both, and the collected data can be analyzed within the respective tools.

Vulnerability details: The NVIDIA NVDebug tool contains a vulnerability that may allow an actor to gain access to restricted components. A successful exploit of this vulnerability may lead to information disclosure.

Ref: CVE-2021-34398: NVIDIA DCGM, all versions prior to 2.2.9, contains a vulnerability in the DIAG module where any user can inject shared libraries into the DCGM server, which is usually running as root, which may lead to privilege escalation, total loss of confidentiality and integrity, and complete denial of service. (Public on May 29, 2025)

Point of view: In attached diagram description, if your system uses NVDebug, it’s very likely that it also includes or interacts with a version of the DCGM library, and therefore could be affected by vulnerabilities in DCGM versions prior to 2.2.9.

Official announcement: Please refer to the supplier announcement –

https://nvidia.custhelp.com/app/answers/detail/a_id/5651

Potential Risk of CVE, System

CVE-2024-55567: A vulnerability in the UsbCoreDxe driver of the InsydeH2O UEFI firmware, specifically due to improper input validation. (16-6-2025)

Leave a comment

NVD Published Date: 06/12/2025

NVD Last Modified: 06/12/2025

Preface: InsydeH2O is a UEFI firmware developed by Insyde Software, used in a wide range of devices from servers to AI PCs. It’s known for its modular architecture, which allows for flexibility and faster development cycles. The kernel likely refers to the core components of this firmware, responsible for low-level hardware interaction and system initialization.

Background: Both CVEs involve UsbCoreDxe and SMRAM interaction.

CVE-2022-30283 is about unsafe memory placement (outside SMRAM).

If a UEFI driver registers an SMI handler but does not properly isolateits memory region, it might place the handler outside SMRAM. This can happen due to incorrect use of SmmInstallProtocolInterface() or similar APIs.

CVE-2024-55567 is about unsafe memory access (inside SMRAM) due to input validation flaws.

CVE-2024-55567 is a vulnerability in the UsbCoreDxe driver of the InsydeH2O UEFI firmware, specifically due to improper input validation. This flaw allows an attacker to write arbitrary memory inside SMRAM, leading to arbitrary code execution at the SMM (System Management Mode).

Vulnerability details: Improper input validation was discovered in UsbCoreDxe in Insyde InsydeH2O kernel 5.4 before 05.47.01, 5.5 before 05.55.01, 5.6 before 05.62.01, and 5.7 before 05.71.01. The SMM module has an SMM call out vulnerability which can be used to write arbitrary memory inside SMRAM and execute arbitrary code at SMM level.

Official announcement: Please see the link for details –

https://nvd.nist.gov/vuln/detail/CVE-2024-55567

Potential Risk of CVE, System

About CVE-2025-37889 – ASoC framework Consistently treat platform_max as control value (12th May 2025)

Leave a comment

Preface: The overall project goal of the ALSA System on Chip (ASoC) layer is to provide better ALSA support for embedded system-on-chip processors.

Advanced Linux Sound Architecture (ALSA) is a software framework and part of the Linux kernel that provides an application programming interface (API) for sound card device drivers.

Background: The snd_soc_put_volsw() function is part of the ALSA System on Chip (ASoC) layer in the Linux kernel. It is included in the kernel source, but whether it is available by default depends on the specific kernel configuration and the presence of ASoC support. Here’s a brief overview of its features:

Purpose: It sets the volume control values for the sound subsystem.

Arguments: It takes two arguments: kcontrol, which represents the mixer control, and ucontrol, which contains the control element information.

Return Value: It returns 0 on success.

Vulnerability details: ASoC: ops: Consistently treat platform_max as control value This reverts commit 9bdd10d57a88 (“ASoC: ops: Shift tested values in snd_soc_put_volsw() by +min”), and makes some additional related updates.

Speculated this is an enhancement and remediation for CVE-2022-48917

In the Linux kernel, the following vulnerability has been resolved: ASoC: ops: Shift tested values in snd_soc_put_volsw() by +min While the $val/$val2 values passed in from userspace are always >= 0 integers, the limits of the control can be signed integers and the $min can be non-zero and less than zero. To correctly validate $val/$val2 against platform_max, add the $min offset to val first. (CVE-2022-48917)

Official announcement: Please see the link for details –

https://nvd.nist.gov/vuln/detail/CVE-2025-37889

Potential Risk of CVE, System

CVE-2025-21983: While kvfree_rcu() itself is not fundamentally flawed, Linux now been resolved by using a more appropriate workqueue. (2nd Apr 2025)

Leave a comment

Preface: The buddy allocator is a well-known memory management algorithm used in the Linux kernel. It is designed to efficiently allocate and deallocate memory in contiguous blocks.

Background: What is RCU usage in the Linux kernel?

Read-copy update (RCU) is a scalable high-performance synchronization mechanism implemented in the Linux kernel. RCU’s novel properties include support for con- current reading and writing, and highly optimized inter- CPU synchronization.

Currently kvfree_rcu() APIs use a system workqueue which is “system_unbound_wq” to driver RCU machinery to reclaim a memory.

In the Linux kernel, the kvfree_rcu() API uses a system workqueue, specifically the system_unbound_wq, to drive RCU (Read-Copy-Update) machinery for memory reclamation. This setup is used to handle deferred memory freeing in a non-blocking manner. However, there was a recent change where the workqueue was switched to WQ_MEM_RECLAIM to ensure that memory reclamation tasks are handled more efficiently and to avoid potential kernel warnings.

Not every Linux API uses the system_unbound_wq to request memory. The system_unbound_wq is a specific type of workqueue used for tasks that are not bound to any particular CPU, allowing them to run on any available CPU. This is useful for tasks that require high concurrency or have wide fluctuations in concurrency levels.

Vulnerability details: The issue with kvfree_rcu() is primarily related to how it uses the system workqueue (system_unbound_wq) for memory reclamation. This can lead to kernel warnings and potential system instability. The warnings indicate that the workqueue framework rules are being violated, which can affect the reliability of the memory reclamation process.

Remedy: So, while kvfree_rcu() itself is not fundamentally flawed, the way it was implemented led to issues that have now been resolved by using a more appropriate workqueue.

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