Preface: Log management allows you to monitor requests at any level (API, database, etc.) and see which are underperforming. Log management is based on log files.
Log files are important data points for security and surveillance, providing a full history of events over time. Beyond operating systems, log files are found in applications, web browsers, hardware, and even email.

Background: It is important to control the sizes of log files on a Linux server because their size always grows over time. Every server has limited resources and too large logs can lead to performance and memory problems, not to mention the loss of precious storage space. This problem is typically solved through log rotation, a process that involves renaming or compressing a log file before it gets too large, and cleaning up old logs to reclaim storage.

Vulnerability details: A vulnerability was found in logrotate in how the state file is created. The state file is used to prevent parallel executions of multiple instances of logrotate by acquiring and releasing a file lock. When the state file does not exist, it is created with world-readable permission, allowing an unprivileged user to lock the state file, stopping any rotation.

Remedy for older releases of logrotate (from 3.17.0 to 3.19.0):

https://github.com/logrotate/logrotate/commit/1f76a381e2caa0603ae3dbc51ed0f1aa0d6658b9
https://github.com/logrotate/logrotate/commit/addbd293242b0b78aa54f054e6c1d249451f137d

Besides users can upgrade to 3.20.1 – https://github.com/logrotate/logrotate/releases/tag/3.20.1

My comment: From security point of view, it is a critical risk. For example, SIEM relies log event to do the correlation function. If such vulnerability happen and log event agent do not have reporting mechanism to confirm the log events activities. It such a way provide a channel to attacker to try the evade activities because alert function will not respond by firing rule.

Preface: The main difference is that FreeRTOS has traditionally been completely open source (MIT license) whereas ThreadX has traditionally been completely commercial / proprietary. Therefore, FreeRTOS is dominating the embedded RTOS market, with something like 20% of new projects using it.

Background: Azure RTOS USBX is a high-performance USB host, device, and on-the-go (OTG) embedded stack. Azure RTOS USBX is fully integrated with Azure RTOS ThreadX and available for all Azure RTOS ThreadX–supported processors.

Azure RTOS USBX has a remarkably small minimal footprint of 10.5 KB of FLASH and 5.1 KB RAM for Azure RTOS USBX Device CDC/ACM support. Azure RTOS USBX Host requires a minimum of 18 KB of FLASH and 25 KB of RAM for CDC/ACM support.

The CDC-ACM class provides a serial interface for connecting devices such as modems to an embedded system. The package provides a CDC-ACM host class driver for a USB stack. The system allows a USB serial port device to be plugged into the host and recognized as a remote serial port.

Vulnerability details: The implementation of ux_device_class_dfu_control_request function does not assure that a buffer overflow will not occur during handling of the DFU UPLOAD command. When an attacker issues the UX_SLAVE_CLASS_DFU_COMMAND_UPLOAD control transfer request with wLenght larger than the buffer size (UX_SLAVE_REQUEST_CONTROL_MAX_LENGTH, 256 bytes), depending on the actual implementation of dfu -> ux_slave_class_dfu_read, a buffer overflow may occur. In example ux_slave_class_dfu_read may read 4096 bytes (or more up to 65k) to a 256 byte buffer ultimately resulting in an overflow. Furthermore in case an attacker has some control over the read flash memory – in example DFU is used with an external SPI flash chip or the DFU DOWNLOAD command may be used – this may result in execution of arbitrary code and platform compromise.

Remedy: This fix has been included in USBX release 6.1.11.

Official announcement: Please refer to the link for details – https://github.com/azure-rtos/usbx/security/advisories/GHSA-hh5p-x584-j8hv

Preface:If the operating system itself contains unknown technical matter. When 3rd party application installed, a vulnerability merely encounter on the specified software. Do you think operating system vendor should do the remedy? Or third party vendor take the responsibility?

Background: Cybersecurity related to functional safety will be included Powergrid, public facilities and manufacturing industry. SCADA systems are used in many different industries to collect and analyze real-time data, as well as to control functions, which makes them a target to malicious hackers.

AVEVA InTouch Access Anywhere enables you to remotely view a running InTouch application from a desktop computer or a mobile device including tablets, smartphones, or laptops. You view and control the application through a secure web browser without requiring a separate client application.
InTouch Access Anywhere provides the following features:
– Provides secure and remote access to InTouch applications.
– Incorporates image compression, packet shaping, and whole frame rendering to improve Internet performance.
– Automatically adjusts the size of your InTouch Access Anywhere session to the web browser window showing the application.
– Supports finger gestures on touch screen devices.
– Works on devices that only support web applications like Chromebooks
– Provides an expandable session toolbar with icons to disconnect your InTouch Access Anywhere sessions, access system keys, and copy application data to your Windows clipboard.

Vulnerability details: Certain versions of AVEVA InTouch Access Anywhere from AVEVA contain the following vulnerability:
Windows OS can be configured to overlay a “language bar” on top of any application. When this OS functionality is enabled, the OS language bar UI will be viewable in the browser alongside the AVEVA InTouch Access Anywhere and Plant SCADA Access Anywhere applications. It is possible to manipulate the Windows OS language bar to launch an OS command prompt, resulting in a context-escape from application into OS.

Remedy:

Application Software Vendor Security Updates – https://www.aveva.com/en/support-and-success/cyber-security-updates/

ICS Advisory (ICSA-22-130-05) – https://www.cisa.gov/uscert/ics/advisories/icsa-22-130-05

Preface: If a company or organization suffers a data breach, a significant concern is what PII might be exposed—the personal data of the customers that do business or otherwise interact with the entity. Exposed PII can be sold on the dark web and used to commit identity theft, putting breach victims at risk.

Background: Within Oracle WebLogic Server 10.3.6, Oracle E-Business Suite Release 12.2 employs Java Database Connectivity (JDBC) data sources to maintain a pool of connections for database connectivity. These JDBC data sources are associated with the managed servers (such as oacore and forms) in which Oracle E-Business Suite applications are deployed.

Based on existing software products included in Oracle E-Business Suite Releases 12.1, 12.2. So the details below will get you there. Maybe this is the answer you are looking for.
R12.1 – OHS 10.1.3.5 is based on Apache 2.0 that is “end of life”
R12.2 – OHS 11.1.1.9 is based on Apache 2.2 which is in EOL since June 2017, but still covered by Oracle support.

Vulnerability details: Vulnerability in Oracle E-Business Suite (component: Manage Proxies). Supported versions that are affected are 12.1 and 12.2. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle E-Business Suite. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle E-Business Suite accessible data.

Official announcement – This Security Alert addresses vulnerability CVE-2022-21500, which affects some deployments of Oracle E-Business Suite. This vulnerability is remotely exploitable without authentication, i.e., may be exploited over a network without the need for a username and password. If successfully exploited, this vulnerability may result in the exposure of personally identifiable information (PII). See the link for details – https://www.oracle.com/security-alerts/alert-cve-2022-21500.html

Preface: Looking back, a vulnerability was discovered in NVIDIA GPU Display Driver on 2016. A flaw exists in the kernel mode layer (nvlddmkm.sys) handler for DxgDdiEscape IDs 0x600000E, 0x600000F, and 0x6000010 due to improper validation of user-supplied input that is used as an index to an internal array. A local attacker can exploit this to corrupt memory, resulting in a denial of service condition or an escalation of privileges.

Background: NVIDIA GPU Display Driver support 2 different operation systems. So called the kernel mode layer (nvlddmkm.sys for Windows or nvidia.ko for Linux).

Vulnerability details: NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer (nvlddmkm.sys) handler for DxgkDdiEscape or IOCTL where an unprivileged regular user can access administrator- privileged registers, which may lead to denial of service, information disclosure, and data tampering. IOCTL in Linux is referred to as Input and Output Control, which is used to talking to device drivers. This system call, available in most driver categories.

Conjecture : Attacker need to know PML4 The actual physical address of the table (CR3 Value) , Otherwise, attacker will not be able to remap the target virtual address to the address he want to control.

There are other ideas.Use Paging table Primitives to destroy bitmaps , And use it GDI Primitive language to restore our relevant mmPfnDatabase entry .

Ref: x64 Used 4 Level page table to map physical memory and virtual memory. This 4 levels are PML4（Page Map Level 4),（Common name ：PXE）,PDPT（Page Directory Pointers）,PD（Page Directory）as well as PT（Page Table）, CR3（ Control register ）that holds the current process PML4 Base address（Physical address).

CR3 enables the processor to translate linear addresses into physical addresses by locating the page directory and page tables for the current task.

Vendor announcement: Security Bulletin: NVIDIA GPU Display Driver – May 2022 – https://nvidia.custhelp.com/app/answers/detail/a_id/5353

Preface: There’s no needle with both ends pointed. The baseline requirements of ETSI EN 303 645 specifically have timely, automatic updates as one of its requirements. So the first step in best practice is to ensure that software updates can be delivered to your system, preferably automatically and over-the-air (OTA).

Background: Traditionally, U-Boot is the most popular boot loader in linux based embedded devices. Das U-Boot is an open-source, primary boot loader used in embedded devices to package the instructions to boot the device’s operating system kernel.
Numerous features and modes of operation can be selected by adding definitions to the board-configuration file. Below example is a partial configuration header file.

define CONFIG_COMMANDS (CONFIG_CMD_DFL & ~CFG_CMD_NFS)

Vulnerability details: An issue was discovered in Das U-Boot through 2019.07. There is an unbounded memcpy with a failed length check at nfs_lookup_reply.
nfs_lookup_reply in net/nfs.c in Das U-Boot through 2022.04 (and through 2022.07-rc2) has an unbounded memcpy with a failed length check, leading to a buffer overflow.

Remark: When you call memcpy you need to pass it two pointers, and the size of the object to copy.

Remedy: Please refer to the link for details – https://github.com/u-boot/u-boot/commit/5d14ee4e53a81055d34ba280cb8fd90330f22a96

Doubt: Once the operating system is loaded, the boot loader transfers control to it and is no longer needed. The operating system will initialize itself, configure the system hardware (e.g., set up memory management, set timers, set interrupts), and load device drivers, if needed.
If there is buffer overflow vulnerability happen in a bootloader. My idea is that the risk rating or impact all depends on the device whether accepted remote process service or accept Updating the Bootloader Over-the-Air (OTA).
In theory, in the out-of-bounds write vulnerability, the software writes data past the end, or before the beginning, of the intended buffer, which can result in the corruption of data, a crash, or code execution.
But in what way to trigger this vulnerability? I have no idea in the moment.

Preface: Traditionally, the only way to enable that syscall in Linux was to enable CONFIG_CHECKPOINT_RESTORE. However, since Linux v5.10.20 and v5.11.3, a new CONFIG_KCMP has been added to Linux to allow enabling sys_kcmp without having to enable CONFIG_CHECKPOINT_RESTORE!

Background: Secure computing mode ( seccomp ) is a Linux kernel feature. You can use it to restrict the actions available within the container. The seccomp() system call operates on the seccomp state of the calling process. You can use this feature to restrict your application’s access. Syscalls are system calls, and they’re the way that you can make requests from user space into the Linux kernel.

In practical, we use syscalls a lot, because even everyday activities like making files or changing directories involve syscalls on Linux.

Vulnerability details: The Linux kernel before 5.17.2 mishandles seccomp permissions. The PTRACE_SEIZE code path allows attackers to bypass intended restrictions on setting the PT_SUSPEND_SECCOMP flag.

Vulnerability found permission checks were done on the PTRACE_SETOPTIONS path. However the PTRACE_SEIZE code path allows attackers to bypass intended restrictions on setting the PT_SUSPEND_SECCOMP flag.
The vulnerability move the permissions checks out into a helper function and let both ptrace_attach() and ptrace_setoptions() call it.

Official announcement (For details, please refer to the official announcement) – https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ee1fee900537b5d9560e9f937402de5ddc8412f3

Preface: Hardware debug modes and processor INIT setting that allow override of locks for some Intel(R) Processors in Intel(R) Boot Guard and Intel(R) TXT may allow an unauthenticated user to potentially enable escalation of privilege via physical access.

Background: Protection Class “Public” (historically also known as “Green” or “Locked”) is where all sets of debuggers can use the available debug capabilities given by this class. No access mechanisms are used by the debugger and the privilege level on the debug capabilities (i.e., Basic Enabling) are considered public and available to everyone.

Intel specified CPU products can utilize two different ways to access the entity debug mechanism to enable access and to gain privileges for debug capabilities. For example: unlock. But the debugger must authenticate and unlock using Intel’s authentication key.

On CVE-2018-3659 and CVE-2018-3643 description does not mention DAM explicitly.
It is well known that DAM does not require authorization from Intel or the system manufacturer but requires the consent of the owner. The consent can be set in the following way:
• On CNP based platform, by physically connecting to Intel® Direct Connect Interface (Intel® DCI) over a USB3 port supporting a dedicated protocol and device for debugging, aka Intel® DCI OOB.
• Having BIOS set consent.
• Setting DCI enable bit in SPI descriptor, i.e. a configuration option that enable/disable automatic debug consent if the system is before EOM. This can be set using Intel Flash Image Tool (FIT).

Vulnerability details and remedy: For details, please refer to the official article (2022.1 IPU – Intel® Boot Guard and Intel® TXT Advisory) – https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00613.html

My observation: According to Risk Rating, Adjacent Network, Authenticated CVSS score of 7.3. Additionally, the unauthenticated physical CVSS score is 7.3. Therefore, undisclosed details of the design weakness include both local and remote access. Attackers exploit remote access to think it is running on a management application. For example, it is the Intel Converged Security and Management Engine (CSME).

In the initialization of the x86-64 multi-core system, one core is required as the bootstrap processor (BSP). Each processor first performs a processor self-test (BIST – Built In Self Test), and if the self-test passes, it has the qualification to become a BSP. Each processor that is expected to become a BSP will send a special cycle of NOP to the bus, with the purpose of reaching the end point as quickly as possible. If a processor successfully sends a NOP first, it becomes a BSP. Vendor recommends updating the Intel Converged Security and Management Engine (CSME) to the latest version, disabling the CPU debug feature when Boot Guard is enabled, and disabling the BSP (Bootstrap Processor) INIT (DBI) bit. Refer to above details, did you speculate what is the fact causes bug happen?

Preface: KVM (Kernel based Virtual Machine) is an open source Linux kernel virtualization infrastructure2 which relies on the hardware virtualization technologies, fully integrated in the Linux kernel. Its first version was introduced in the 2.6.20 Linux kernel tree (released in February 2007). KVM developers are primarily funded by a technology startup called Qumranet, now owned by RedHat. Developers had an original approach. Instead of creating major portions of an operating system kernel themselves, they choose to use the Linux kernel itself as a basis for a hypervisor.

KVM stands for Kernel-based Virtual Machine. Being an open-source virtualization software that’s embedded into Linux, KVM does two things:

• Makes Linux a hypervisor
• Enables Linux to run multiple, isolated virtual environments

KVM initially supported x86 platform processors and was subsequently ported to S/390, PowerPC, and IA-64 platforms

Background: AMD EPYC 7002 Processors – A dual-socket AMD EPYC workstation or server is idea for compute intensive tasks such as high performance computing (HPC) and artificial intelligence (AI) applications thanks to their huge memory bandwidth, memory capacity and outstanding I/O. AMD EPYC Processors with improved execution pipelines, higher clock rates, and up to 4x the shared Level 3 cache. A Level 3 (L3) cache is a specialized cache that that is used by the CPU and is usually built onto the motherboard and, in certain special processors, within the CPU module itself.

The AMD EPYC 7002 Series Processor is the latest generation of the AMD64 System-on-Chip (SoC) processor family. It is based on the Zen 2 microarchitecture introduced in 2019, supporting up to 64 cores (128 threads) and 8 memory channels per socket. AMD’s CCD is actually an abbreviation of Core Chiclet Die.The Zen 2 architecture processor is not a large core packaged together, but is divided into two parts: the CCD core and the I/O core, of which the CCD core is a pure computing The core contains two CCXs, that is, each CCD has 8 cores and 16 threads.

Vulnerability details: An attacker with access to a malicious hypervisor may be able to infer data values used in a SEV guest on AMD CPUs by monitoring ciphertext values over time.

Speculation based on vulnerabilities: If important data is encrypted at rest or in transit, it’s often best to try to steal the data when it’s not encrypted by monitoring the memory space of the process performing the encryption and any calls to cryptographic libraries.

Official announcement: AMD provides preventive and corrective controls, please refer to the link for more details. https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1033

My comment: Due to this design flaw, the vendor (AMD) recommend to do a series of preventive and corrective control. In my personal point of view, the first step should dicuss with system architect and software development how to integrate below concept of Linux clear cache command into the work flow.
Drop all caches – Below Linux command:
sync; echo 3 > /proc/sys/vm/drop_caches

Preface: Google Pixel is a brand of consumer electronic devices developed by Google that run either Chrome OS or the Android operating system. The Pixel brand was introduced in February 2013 with the first-generation Chromebook Pixel. The Pixel line includes laptops, tablets, and smartphones, as well as several accessories.

Background: The Google Pixel is one of the smartphones on the market today. The Google Pixel also works with digital camera products.

How do you identify a Pixel device? The simple way is to go through the settings menu. → Settings → About Phone → Model Number. The display will tell you the make and model number of your device alongside the IMEI Number, serial number and also the version of Android you are running.

How do I get into bootloader? Follow below steps:

• Ensure the phone is turned off.
• Press and hold the VOLUME DOWN button.
• Press the POWER button.
• Continue to hold VOLUME DOWN until the Download mode is displayed.
• Press VOLUME DOWN to go to Reboot to bootloader.
• Press the POWER button.

Vulnerability details: With just a few minutes of physical access and a USB cable, attackers can silently and invisibly compromise unpatched devices. The exact details of the vulnerability have not been disclosed. Do you think the key factor whether similar to steps displayed in attached diagram?

Official announcement (Pixel Update Bulletin—May 2022): Please refer to the link for details – https://source.android.com/security/bulletin/pixel/2022-05-01#pixel