A new unnamed vulnerability class has been detected in the Windows 11 Kernel that could allow a threat actor to execute arbitrary code with Kernel privileges.
This vulnerability, named “File Immutability,” exists due to incorrect assumptions in the design of the Core Windows feature. These assumptions can result in undefined Behaviour and security vulnerabilities.
The list of components and concepts associated with this “File Immutability” vulnerability is as follows:
- Windows File sharing – Full set of access right
- Memory Manager – treats PE-relocated pages as unmodified, dynamically reapplying relocations during page faults.
- Sharing enforcement – the responsibility of the filesystem driver to call IoCheckShareAccess or IoCheckLinkShareAccess to see whether the requested DesiredAccess/ShareMode tuple is compatible
- Authenticode – describes a way to employ cryptography to “sign” PE files
- Code Integrity – validates signatures in the kernel
- Incorrect assumptions – implies that files successfully opened without write sharing can’t be modified by another user or process.
- Page hashes – list of hashes of each 4KB page within a PE file
- Network redirectors – allow the use of network paths with any API that accepts file paths
- Protected Process Light (PPL) – Anti-Malware services run as Protected Process Light (PPL), protecting them from tampering by malware with admin rights, so the ransomware can’t terminate the Anti-Malware service.
An attacker can utilize this false file immutability by employing a network redirector to modify PPL’s DLL Server-side and bypass sharing restrictions.
In this case, the PE’s backing an executable image are incorrectly assumed to be immutable. However, this class of vulnerability is called “False File Immutability.”
Further, this vulnerability was also presented at Black Hat Asia 2023. A Windows Kernel vulnerability was disclosed, indicating how bad assumptions in paging can be exploited to inject code into PPL by defeating security features like LSA and Anti-Malware Process Protection.
The attack used False File immutability assumptions for DLLs in PPLs for the presented scenario.
New Research
This new vulnerability report, published by Elastic Security, uses authenticode signatures embedded within PE files, which use a detached signature called Security Catalog.
Every PE with an authentihash in the list is considered to be signed by that signer to which Windows keeps a large collection of catalog files in C:WindowsSystem32CatRoot.
Initially, the CI (Code Integrity) maps the file into kernel memory using ZwOpenFile, ZwCreateSection, and ZwMapViewOfSection and then validates the catalog’s digital signature using CI!MinCrypK_VerifySignedDataKModeEx.
If the signature is valid, it parses the hashes with CI!I_MapFileHashes.
After this, the file is opened without FILE_SHARE_WRITE, which means the write sharing is denied.
However, this is intended to prevent modification of the security catalog during processing. Nevertheless, this is a bad assumption and another example of False File Immutability.
Attack Planning
The attack flow starts with an attacker planting a security catalog on a storage device they control.
Then, they will install a symbolic link to this catalog in the CatRoot directory to ensure Windows can find it.
Proceeding further with the attack, the attacker can perform the following actions to exploit this vulnerability:
- Asks the Kernel to load a malicious unsigned Kernel driver
- Code Integrity attempts to validate the driver, but it can’t find a signature or trusted authentihash, so it re-scans the CatRoot directory and finds the attacker’s new catalog.
- CI maps the catalog into kernel memory and validates its signature. This generates page faults, which are sent to the attacker’s storage device. The storage device returns a legitimate Microsoft-signed catalog.
- The attacker empties the system working set, forcing all the previously-fetched catalog pages to be discarded.
- CI begins parsing the catalog, generating new page faults. This time, the storage device injects the authentihash of their malicious driver.
- CI finds the malicious driver’s authentihash in the catalog and loads the driver. At this point, the attacker has achieved arbitrary code execution in the kernel.
Double Read Vulnerability and Attack
.webp)
This vulnerability can arise when the victim code reads the same value from an attacker-controlled buffer more than once.
The threat actor may change the value of this buffer between the reads, resulting in unexpected victim behavior.
However, the attack pattern can be executed by setting a packet’s structure’s length field to 16 bytes and then signaling the server to indicate that a packet is ready for processing.
The victim server wakes up and allocates a 16-byte buffer using malloc(pPacket->length). The attacker then changes the length field to 32.
Next, the victim server attempts to copy the packet’s contents into the the new buffer by calling memcpy(pBuffer, pPacket->data, pPacket->length), re-reading the value in pPacket->length, which is now 32.
The victim ends up copying 32 bytes into a 16-byte buffer, overflowing it.
Affected Operations
| Operation | API | Mitigations |
| Image Sections | CreateProcess LoadLibrary | 1. Enable Page Hashes |
| Data Sections | MapViewOfFile ZwMapViewOfSection | 1. Avoid double reads 2. Copy the file to a heap buffer before processing 3. Prevent paging via MmProbeAndLockPages/VirtualLock |
| Regular I/O | ReadFile ZwReadFile | 1. Avoid double reads 2. Copy the file to a heap buffer before processing |
Protect Your Business Emails From Spoofing, Phishing & BEC with AI-Powered Security | Free Demo