Category Archives: System

CVE-2023-20597: AGESA™ firmware versions previously provided did not sufficiently mitigate CVE-2023-20594. Release 2nd round of remedy.(13-June-2024)

Preface: June 2024 Update – After additional analysis, AMD believes that the Client AGESA™ firmware versions previously provided did not sufficiently mitigate CVE-2023-20594. This security bulletin has been updated with new Client AGESA™ firmware versions that contain updated mitigations.

Background: The DXE drivers are responsible for initializing the processor, chipset, and platform components as well as providing software abstractions for system services, console devices, and boot devices.

Vulnerability details:

CVE-2023-20594Improper initialization of variables in the DXE driver may allow a privileged user to leak sensitive information via local access.
CWE-665 Improper Initialization

CVE-2023-20597 Improper initialization of variables in the DXE driver may allow a privileged user to leak sensitive information via local access.
CWE-665 Improper Initialization

Published Date: Sep 20, 2023
Last updated date: Jun 11, 2024

Official announcement: For detail, please refer to link –
https://www.amd.com/en/resources/product-security/bulletin/amd-sb-4007.html

CVE-2024-38016: tty: n_gsm: fix possible out-of-bounds in gsm0_receive() (29-05-2024)

Preface: In the Linux Kernels n_gsm serial line discipline, which can be exploited by local attackers to gain kernel level root access. It original published by other Linux brand on 8th May 2024.

Background: In Unix systems, a tty (which is short for “teletypewriter”) is the standard representation of a terminal device, with at least input and output capabilities and usually much more. These were originally connected to serial ports, but most today are virtual terminals, connected to either a text-mode console (DOS-like) or a graphical terminal program (like xterm or gnome-terminal).

Vulnerability details: tty: n_gsm: fix possible out-of-bounds in gsm0_receive()

Assuming the following:

– side A configures the n_gsm in basic option mode

– side B sends the header of a basic option mode frame with data length 1

– side A switches to advanced option mode

– side B sends 2 data bytes which exceeds gsm->len

Reason: gsm->len is not used in advanced option mode.

– side A switches to basic option mode

– side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration.

Official details: For detail, please refer to link – https://www.tenable.com/cve/CVE-2024-36016

Red Hat security advisory: Important – glibc security update (29-05-2024)

Preface: You can clear the cache of nscd by performing the following actions:

Execute the following command: sudo /etc/init[.]d/nscd restart.

Background:

Nscd is a daemon that provides a cache for the most common name service requests. The default configuration file, /etc/nscd. conf, determines the behavior of the cache daemon.

The glibc packages provide the standard C libraries (libc), POSIX thread libraries (libpthread), standard math libraries (libm), and the name service cache daemon (nscd) used by multiple programs on the system. Without these libraries, the Linux system cannot function correctly.

The iconv() function shall convert the sequence of characters from one codeset, in the array specified by inbuf, into a sequence of corresponding characters in another codeset, in the array specified by outbuf. The codesets are those specified in the iconv_open() call that returned the conversion descriptor, cd.

Vulnerability details:

glibc: Out of bounds write in iconv may lead to remote code execution (CVE-2024-2961)

glibc: stack-based buffer overflow in netgroup cache (CVE-2024-33599)

 glibc: null pointer dereferences after failed netgroup cache insertion (CVE-2024-33600)

 glibc: netgroup cache may terminate daemon on memory allocation failure (CVE-2024-33601)

 glibc: netgroup cache assumes NSS callback uses in-buffer strings (CVE-2024-33602)

Official announcement: For detail, please refer to link – https://access.redhat.com/errata/RHSA-2024:3464

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

CVE-2024-4017 and CVE-2024-4018 on BeyondTrust (19-04-2024)

Preface: CyberArk most likely to be known as a leader in PAM. BeyondTrust more popular among small and medium-sized enterprises.

Background: U-Series is a self-contained physical or virtual appliance that contains the operating system, the database, the BeyondTrust BeyondInsight platform, and the BeyondTrust Password Safe solution.

For a BeyondInsight deployment with a local SQL Server instance, the minimum requirement is 32GB. It is based on Microsoft Windows Server 2022 Standard operating system. The license included with the U-Series v20 and U-Series v20 SQL Free for Microsoft Windows Server 2022 covers up to 16 cores on the physical virtualization (host) server.

Vulnerability details:

CVE-2024-4018: Improper Privilege Management vulnerability in BeyondTrust U-Series Appliance on Windows, 64 bit (local appliance api modules) allows Privilege Escalation.This issue affects U-Series Appliance: from 3.4 before 4.0.3. Please refer to the link for details – https://nvd.nist.gov/vuln/detail/CVE-2024-4018

CVE-2024-4017: Improper Privilege Management vulnerability in BeyondTrust U-Series Appliance on Windows, 64 bit (filesystem modules) allows DLL Side-Loading.This issue affects U-Series Appliance: from 3.4 before 4.0.3. Please refer to the link for details –

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

Why does Arm not affected by CVE-2024-2201? (11-Apr-2024)

Preface: I believed that similar type of design weakness known last year by Arm (Feb 2023). May be it fixed it already.

Background: Linux kernel on Intel systems is susceptible to Spectre v2 attacks. CVE-2022-0001 explained Non-transparent sharing of branch predictor selectors between contexts in some Intel(R) Processors may allow an authorized user to potentially enable information disclosure via local access. On 9th April, 2024 Dr. Elke Drennan published an article focus an attacker with access to CPU resources may be able to read arbitrary privileged data or system registry values by speculatively jumping to a chosen gadget. When you read the details, you will find that AMD and ARM are not affected. Why?

Vulnerability details: An attacker with access to CPU resources may be able to read arbitrary privileged data or system registry values by speculatively jumping to a chosen gadget.

Solution: Please update your software according to the recommendations from respective vendors with the latest mitigations available to address this vulnerability and its variants.

Official announcement: Please refer to the link for details- https://www.kb.cert.org/vuls/id/155143

When Intel met Heckle – hypervisor’s interrupt injection behavior on Intel TDX  (10th April 2024)

Technical report shared by ETH Zurich on 4th April 2024: Please refer to the link for details – https://arxiv.org/html/2404.03387v1

Background: Intel CPU’s inbuilt TDX Module provides an interface for the hypervisor to manage VMs indirectly and offers new instructions, VMLAUNCH-VMX and VMRESUME, for starting and resuming a VM. Instead of keeping track of the owner for each memory page on a system wide basis, TDX relies on keeping one shared extended page table for the hypervisor and multiple private extended page tables for each virtual machine (called TD by Intel).

Reference: int means interrupt, and the number 0x80 is the interrupt number. An interrupt transfers the program flow to whomever is handling that interrupt, which is interrupt 0x80 in this case. In Linux, 0x80 interrupt handler is the kernel, and is used to make system calls to the kernel by other programs.

The kernel is notified about which system call the program wants to make, by examining the value in the register %eax (AT&T syntax, and EAX in Intel syntax). Each system call have different requirements about the use of the other registers. For example, a value of 1 in %eax means a system call of exit(), and the value in %ebx holds the value of the status code for exit().

Vulnerability details: The test implement a kernel module in 150 LoC to inject interrupts into the TDX VM. Our host module uses kernel hooks to call a function in KVM that is used to deliver int 0x80 interrupts to TDX VMs. Unlike SEV-SNP, TDX does not expose the Virtual Machine Control Structure (VMCS) or the virtual APIC pages to the untrusted hypervisor. Instead, it expects the hypervisor to write into a Posted Interrupt Request (PIR) buffer. This buffer is used by hardware to inject interrupts into TDX VMs through the virtual APIC [34]. We inject two interrupts into two different cores of the CVM with this mechanism, one to gain login into the TDX VM with OpenSSH and another to get root access with sudo. During these two injects, the guest kernel does not acknowledge the interrupts. While this does not stop our attacks, it does leave the APIC with an elevated Task-Priority-Register (TPR), blocking all lower-priority interrupts on the affected vCPU. This may break CVM functionality that is noticeable by the user. To evade such detection, we implement a guest kernel module (kern_ack) that resets the APIC state. We inject this kernel module into the TDX VM as the last part of our attack after gaining root access.

AMD response to technical article (Heckler – Disrupting AMD SEV-SNP with interrupts) (9th Apr 2024)

Preface: AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) is a feature of AMD EPYC processors that adds strong memory integrity protection to help prevent malicious hypervisor-based attacks in order to create an isolated execution environment.

Background: Fundamentally, int means interrupt, and the number 0x80is the interrupt number. An interrupt transfers the program flow to whomever is handling that interrupt, which is interrupt 0x80 in this case. In Linux, 0x80 interrupt handler is the kernel, and is used to make system calls to the kernel by other programs.

In current Linux, 32-bit syscalls (including int 0x80 from 64-bit) eventually end up indo_syscall_32_irqs_on(struct pt_regs *regs). It dispatches to a function pointer ia32_sys_call_table, with 6 zero-extended args. This maybe avoids needing a wrapper around the 64-bit native syscall function in more cases to preserve that behaviour, so more of the ia32 table entries can be the native system call implementation directly.

Vulnerability details: Researchers from ETH Zurich have shared with AMD a paper titled “Heckler: Disrupting AMD SEV-SNP with Interrupts.”

In their paper, the researchers report that a malicious hypervisor can potentially break confidentiality and integrity of Linux® SEV-SNP guests by injecting interrupts. 

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

Supply constraints and product attribute design. It is expected that two camps will be operated in the future. (9th JAN 2024)

Preface: When High performance cluster (HPC) was born, it destiny do a competition with traditional mainframe technology.  The major component of HPC is the multicore processor. That is GPU. For example: The NVIDIA GA100 GPU is composed of multiple GPU Processing Clusters (GPCs), Texture Processing Clusters (TPCs), Streaming Multiprocessors (SMs), and HBM2 memory controllers. Compare with the best of the best setup,  the world’s fastest public supercomputer, Frontier, has 37,000 AMD Instinct 250X GPUs.

How to break through traditional computer technology and go from serial to parallel processing: CPUs are fast, but they work by quickly executing a series of tasks, which requires a lot of interactivity. This is known as serial processing. GPU parallel computing is a type of computation in which many calculations or processes are carried out simultaneously. As time goes by. Until the revolution in GPU processor technology and high-performance clusters. RedHat created a High Performance Cluster system configuration. The overall performance is close to that of a supercomputer processor using crossbar switches. But the bottleneck lies in how to transform traditional software applications from serial processing to parallel processing.

Reflection of reality in the technological world: A common consense that GPU processor manufacturer Nvidia had strong market share in the world. The Nvidia A100 processor delivers strong performance on intensive AI tasks and deep learning. A more budget-friendly option, the H100 can be preferred for graphics-intensive tasks. The H100’s optimizations, such as TensorRT-LLM and NVLink, show that it surpasses the A100, especially in the LLM area. Large Language Models (LLMs) have revolutionised the field of natural language processing. As these models grow in size and complexity, the computational demands for inference also increase significantly. To tackle this challenge, leveraging multiple GPUs becomes essential.

Supply constraints and product attribute design create headaches for web hosting providers: CUDA is a parallel computing platform and programming model developed by NVIDIA for general computing on graphical processing units (GPUs). But converting serial C code to data parallel code is a difficult problem. Because of this limitation. Nvidia develop NVIDIA CUDA Compiler (NVCC). This software is a proprietary compiler by Nvidia intended for use with CUDA.

Using the CUDA Toolkit you can accelerate your C or C++ applications by updating the computationally intensive portions of your code to run on GPUs. To accelerate your applications, you can call functions from drop-in libraries as well as develop custom applications using languages including C, C++, Fortran and Python.

But you cannot use CUDA without a Nvidia Graphics Card. CUDA is a framework developed by Nvidia that allows people with a Nvidia Graphics Card to use GPU acceleration when it comes to deep learning, and not having a Nvidia graphics card defeats that purpose. (Refer to attached Diagram Part 1).

If web hosting service provider not use NVIDIA product, is it possible to use other brand GPU processor for AI machine learning? Yes, you can select OpenCilk.

OpenCilk (http://opencilk.org) is a new open-source platform to support task-parallel programming in C/C++. (Refer to attached Diagram Part 2)

Referring to the above details, the technological development atmosphere makes people foresee that two camps will operate in the future. This is the Nvidia camp and the non-Nvidia camp. This is why I have observed that web hosting service providers are giving themselves headaches in this new trend in technology gaming.

CVE-2023-34326: Potential risk allowing access to unindented memory regions (8th JAN 2024)

Preface: In fact, by the time the vulnerability was released to the public, the design limitations and/or flaws had already been fixed. You may ask, what is the discussion space for the discovered vulnerabilities? As you know, an increasing number of vendors remain compliant with CVE policies, but the technical details will not be disclosed. If your focus is understanding, even if the vendor doesn’t release any details. You can learn about specific techniques as you learn. The techniques you learn can expand your horizons.

Background: AMD-Vi represents an I/O memory management unit (IOMMU) that is embedded in the chipset of the AMD Opteron 6000 Series platform. IOMMU is a key technology in extending the CPU’s virtual memory to GPUs to enable heterogeneous computing. AMD-Vi (also known as AMD IOMMU) to allow for PCI Passthrough.

DMA mapping is a conversion from virtual addressed memory to a memory which is DMA-able on physical addresses (actually bus addresses).

DMA remapping maps virtual addresses in DMA operations to physical addresses in the processor’s memory address space. Similar to MMU, IOMMU uses a multi-level page table to keep track of the IOVA-to-PA mappings at different page-size granularity (e.g., 4-KiB, 2-MiB, and 1-GiB pages). The hardware also implements a cache (aka IOTLB) of page table entries to speed up translations.

AMD processors use two distinct IOTLBs for caching Page Directory Entry (PDE) and Page Table Entry (PTE) (AMD, 2021; Kegel et al., 2016).

Ref: If your application scenario does not require virtualization, then disable AMD Virtualization Technology. With virtualization disabled, also, disable AMD IOMMU. It can cause differences in latency for memory access. Finally, also disable SR-IOV.

Vulnerability details: The caching invalidation guidelines from the AMD-Vi specification (48882—Rev 3.07-PUB—Oct 2022) is incorrect on some hardware, as devices will malfunction (see stale DMA mappings) if some fields of the DTE are updated but the IOMMU TLB is not flushed. Such stale DMA mappings can point to memory ranges not owned by the guest, thus allowing access to unindented memory regions.

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