Preface: This design weakness was released 30th Jan 2023. However, this vulnerability is known as CVE-2022-42292 since 10/03/2022. But it already been fixed.

Background: The GeForce Experience features a host of performance and configuration tweaks for games, automatic driver updates for your GPU, Nvidia Shadowplay for live streaming, integrated game filters (like Instagram filters but for your PC games), and many more powerful options.

Vulnerability details: NVIDIA GeForce Experience contains a vulnerability in the NVContainer component, where a user without administrator privileges can create a symbolic link to a file that requires elevated privileges to write to or modify, which may lead to denial of service, escalation of privilege or limited data tampering.

Official announcement: For details, see the link – https://nvidia.custhelp.com/app/answers/detail/a_id/5384/kw/cve-2022-42292

My observation:
I speculate that this vulnerability will affect home users rather than business users. Since the domain user account has best practice Windows access control policies which driven by IT department.

For your reference:
Symbolic links have irrelevant access permissions. Users are only prevented from operating on a symlink by the permissions of its parent directory and the target file. Windows 11 doesn’t require administrative privileges to create symbolic links.

Apart from above concern. Actually, it’s easy to setup access restrictions for home user. You can do it yourself.

Enable Administrator account on Windows 11 from Command Prompt
1. Open Start on Windows 11.
2. Run “Command Prompt”, right-click the top result, and select the Run as administrator option.
3. Type the following command to enable the Windows 11 Administrator account and press Enter: net user “Administrator” /active:yes.

Preface: What is the benefits of corrective action. A motivation to maintain sustainability.

Background: Background: X.509 describes an approach to providing and managing authentication using asymmetric cryptography, generally referred to as Public Key Infrastructure (PKI).
If X.400 defined authentication mechanism using x.509 PKI:
It enhance end to end services for content integrity, message origin authentication and message sequence integrity.

Certificate extensions were introduced in version 3 of the X. 509 standard for certificates. These v3 extensions allow certificates to be customized to applications by supporting the addition of arbitrary fields in the certificate.

OpenSSL itself uses the GENERAL_NAME_cmp function for two purposes:
1) Comparing CRL distribution point names between an available CRL and a CRL distribution point embedded in an X509 certificate
2) When verifying that a timestamp response token signer matches the timestamp authority name (exposed via the API functions TS_RESP_verify_response and TS_RESP_verify_token) .

Vulnerability details: There is a type confusion vulnerability relating to X.400 address processing inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING but the public structure definition for GENERAL_NAME incorrectly specified the type of the x400Address field as ASN1_TYPE. This field is subsequently interpreted by the OpenSSL function GENERAL_NAME_cmp as an ASN1_TYPE rather than an ASN1_STRING. When CRL checking is enabled (i.e. the application sets the X509_V_FLAG_CRL_CHECK flag), this vulnerability may allow an attacker to pass arbitrary pointers to a memcmp call, enabling them to read memory contents or enact a denial of service. In most cases, the attack requires the attacker to provide both the certificate chain and CRL, neither of which need to have a valid signature. If the attacker only controls one of these inputs, the other input must already contain an X.400 address as a CRL distribution point, which is uncommon. As such, this vulnerability is most likely to only affect applications which have implemented their own functionality for retrieving CRLs over a network.

My observation: Whether the attacker use a vulnerability exploit method similar to CVE-2020-1971 as an attack?
OpenSSL’s s_server, s_client and verify mechanism have support for the “-crl_download” option which implements automatic CRL downloading and this attack has been demonstrated to work against those mechanism. The way is that affected versions of OpenSSL cannot parse or construct correct encodings of EDIPARTYNAME. However it is possible to construct a malformed EDIPARTYNAME that OpenSSL’s parser will accept and hence trigger this attack.

Official announcement: For details, see the link (below):

https://nvd.nist.gov/vuln/detail/CVE-2023-0401
https://www.openssl.org/news/secadv/20230207.txt

Preface: As time goes by, Log management is a mandatory setting in the digital world. Log management core architecture design involves a lot of software design. Therefore, you will be exposed to different forms of cyber attacks. So you need to watch out and protect yourself from harm.

Background: Log Insight includes the following key capabilities
• Integrates with VMware vRealize Operations™ to bring unstructured and structured data together, for significantly enhanced end-to-end operations management.

System Features:
Web Hooks supports additional alerting extensibility into Slack,etc.
• Simple Query API adds support for simple keyword search, complex queries, integration with CMDBs, external UI analysis,etc.
• Support for pure IPV6 environment – both server and agent side.
• Server side Agent upgrades – supports automatic agent upgrades

Remark: Working with webhooks exposes an HTTP endpoint that can be called from any actor on your server. Without appropriate measures, this could be extremely unsafe. For example: A man-in-the-middle attack is a vulnerability where a third party obtains access to your webhook data by capturing and reading the request.

Vulnerability details: VMware vRealize Log Insight contains an Information Disclosure Vulnerability. A malicious actor can remotely collect sensitive session and application information without authentication.

Affected Versions: VMware vRealize Log Insight 8.x prior to 8.10.2.

Consequence: Successful exploitation of the vulnerability may allow remote code execution and complete system compromise.

Official announcement: For more information please refer to – https://www.vmware.com/security/advisories/VMSA-2023-0001.html

Preface: As usual when you read a vulnerability bulletin. The vendor sometimes do not disclose technical details to the public. If you will read daily renewal CVE records. Maybe you feel the same way I do. CPU is one of the key topics of the vulnerability database. Since the supplier has the right to secrecy. As a computer user, all you have to do is patch.

Background: AMD engineers that made the “Zen” architecture powering every AMD processor available today, from AMD Ryzen™ desktop and mobile processors, to AMD EPYC™ CPUs, and AMD Threadripper™ CPUs. It all started with “Zen”. AMD Epyc CPU codenames follow the naming scheme of Italian cities, including Milan (3rd Gen 2021), Rome (2nd Gen 2019) and Naples (1st Gen 2017).
The system management unit (SMU) is tasked with the job of continuously sampling sensory data and making rapid corrections to various circuits on the chip.
Ryzen SMU is a Linux kernel driver that exposes access to the SMU (System Management Unit) for certain AMD Ryzen Processors.

Vulnerability details: Insufficient input validation in the SMU may allow an attacker to improperly lock resources, potentially resulting in a denial of service.

Reference: Traditionally, There are two main types of kernel locks. The fundamental type is the spinlock (include/asm/spinlock[.]h). The second type is a mutex (include/linux/mutex[.]h): it is like a spinlock, but you may block holding a mutex.

For official announcement on AMD Server Vulnerabilities – January 2023. Please refer to url – https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1032

Remark: If you’re interested in the matter, see the diagram for details.

Preface: The basic idea behind AIO is to allow a process to initiate a number of I/O operations without having to block or wait for any to complete.

Background: System calls are how a program enters the kernel to perform some task. Programs use system calls to perform a variety of operations such as: creating processes, doing network , file IO,…etc.
io_uring is an asynchronous I/O interface provided by Linux. The implementation of io_uring uses only three syscalls: io_uring_setup, io_uring_enter and io_uring_register.
io_uring gets its name from ring buffers which are shared between user space and kernel space.

There is a size limit of 1GiB per buffer. Currently, the buffers must be anonymous, non-file-backed memory, such as that returned by malloc(3) or mmap(2) with the MAP_ANONYMOUS flag set.
Do you think it is possible to launch a remote attack through this vulnerability (CVE-2023-0240)? Perhaps possible. It can exploit Kernel Driver mmap Handler Exploitation.

Ref: The use-after-free vulnerability exploits a mistake made by the original author of a software and can result in devastating effects that range from remote code execution to the leaking of sensitive data.

Vulnerability details: There is a logic error in io_uring’s implementation which can be used to trigger a use-after-free vulnerability leading to privilege escalation. In the io_prep_async_work function the assumption that the last io_grab_identity call cannot return false is not true, and in this case the function will use the init_cred or the previous linked requests identity to do operations instead of using the current identity. This can lead to reference counting issues causing use-after-free. We recommend upgrading past version 5.10.161.

Official announcement: For details, please refer to the URL – https://nvd.nist.gov/vuln/detail/CVE-2023-0240