{"id":56544,"date":"2024-07-11T18:37:01","date_gmt":"2024-07-11T18:37:01","guid":{"rendered":"https:\/\/packetstormsecurity.com\/news\/view\/36095\/Introducing-A-New-Vulnerability-Class-False-File-Immutability.html"},"modified":"2024-07-11T18:37:01","modified_gmt":"2024-07-11T18:37:01","slug":"introducing-a-new-vulnerability-class-false-file-immutability","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/introducing-a-new-vulnerability-class-false-file-immutability\/","title":{"rendered":"Introducing A New Vulnerability Class: False File Immutability"},"content":{"rendered":"

This article will discuss a previously-unnamed vulnerability class in Windows, showing how long-standing incorrect assumptions in the design of core Windows features can result in both undefined behavior and security vulnerabilities. We will demonstrate how one such vulnerability in the Windows 11 kernel can be exploited to achieve arbitrary code execution with kernel privileges.<\/p>\n

When an application opens a file on Windows, it typically uses some form of the Win32 CreateFile<\/strong><\/a> API.<\/p>\n

HANDLE CreateFileW( [in] LPCWSTR lpFileName, [in] DWORD dwDesiredAccess, [in] DWORD dwShareMode, [in, optional] LPSECURITY_ATTRIBUTES lpSecurityAttributes, [in] DWORD dwCreationDisposition, [in] DWORD dwFlagsAndAttributes, [in, optional] HANDLE hTemplateFile\n);<\/code><\/pre>\n
Callers of CreateFile<\/strong> specify the access they want in dwDesiredAccess<\/strong>. For example, a caller would pass FILE_READ_DATA<\/strong> to be able to read data, or FILE_WRITE_DATA<\/strong> to be able to write data. The full set of access rights are documented<\/a> on the Microsoft Learn website.<\/p>\n
In addition to passing dwDesiredAccess<\/strong>, callers must pass a \u201csharing mode\u201d in dwShareMode<\/strong>, which consists of zero or more of FILE_SHARE_READ<\/strong>, FILE_SHARE_WRITE<\/strong>, and FILE_SHARE_DELETE<\/strong>. You can think of a sharing mode as the caller declaring \u201cI\u2019m okay with others doing X to this file while I\u2019m using it,\u201d where X could be reading, writing, or renaming. For example, a caller that passes FILE_SHARE_WRITE<\/strong> allows others to write the file while they are working with it.<\/p>\n
As a file is opened, the caller\u2019s dwDesiredAccess<\/strong> is tested against the dwShareMode<\/strong> of all existing file handles. Simultaneously, the caller\u2019s dwShareMode<\/strong> is tested against the previously-granted dwDesiredAccess<\/strong> of all existing handles to that file. If either of these tests fail, then CreateFile<\/strong> fails with a sharing violation.<\/p>\n
Sharing isn\u2019t mandatory. Callers can pass a share mode of zero to obtain exclusive access. Per Microsoft documentation<\/a>:<\/p>\n
\n
An open file that is not shared (dwShareMode set to zero) cannot be opened again, either by the application that opened it or by another application, until its handle has been closed. This is also referred to as exclusive access.<\/p>\n<\/blockquote>\n
<\/span>Sharing enforcement<\/h2>\n
In the kernel, sharing is enforced by filesystem drivers. As a file is opened, it\u2019s the responsibility of the filesystem driver to call IoCheckShareAccess<\/strong><\/a> or IoCheckLinkShareAccess<\/strong><\/a> to see whether the requested DesiredAccess<\/strong>\/ShareMode<\/strong> tuple is compatible with any existing handles to the file being opened. NTFS<\/a> is the primary filesystem on Windows, but it\u2019s closed-source, so for illustrative purposes we\u2019ll instead look at Microsoft\u2019s FastFAT sample code performing the same check<\/a>. Unlike an IDA decompilation, it even comes with comments!<\/p>\n
\/\/\n\/\/ Check if the Fcb has the proper share access.\n\/\/ return IoCheckShareAccess( *DesiredAccess, ShareAccess, FileObject, &FcbOrDcb->ShareAccess, FALSE );<\/code><\/pre>\n
In addition to traditional read\/write file operations, Windows lets applications map files into memory. Before we go deeper, it\u2019s important to understand that section objects<\/a> are kernel parlance for file mappings<\/a>; they are the same thing. This article focuses on the kernel, so it will primarily refer to them as section objects.<\/p>\n
There are two types of section objects – data sections and executable image sections. Data sections are direct 1:1 mappings of files into memory. The file\u2019s contents will appear in memory exactly as they do on disk. Data sections also have uniform memory permissions for the entire memory range. With respect to the underlying file, data sections can be either read-only or read-write. A read-write view of a file enables a process to read or write the file\u2019s contents by reading\/writing memory within its own address space.<\/p>\n
Executable image sections (sometimes abbreviated to image sections) prepare PE files<\/a> to be executed. Image sections must be created from PE files. Examples of PE files include EXE, DLL, SYS, CPL, SCR, and OCX files. The kernel processes the PEs specially to prepare them to be executed. Different PE regions will be mapped in memory with different page permissions, depending on their metadata. Image views are copy-on-write<\/a>, meaning any changes in memory will be saved to the process\u2019s private working set \u2014 never written to the backing PE.<\/p>\n
Let\u2019s say application A wants to map a file into memory with a data section. First, it opens that file with an API such as ZwCreateFile<\/strong>, which returns a file handle. Next, it passes this file handle to an API such as ZwCreateSection<\/strong> which creates a section object that describes how the file will be mapped into memory; this yields a section handle. The process then uses the section handle to map a \u201cview\u201d of that section into the process address space, completing the memory mapping.<\/p>\n
\"Diagram
Diagram showing how a file is mapped into memory<\/figcaption><\/figure>\n
Once the file is successfully mapped, process A can close both the file and section handles, leaving zero open handles to the file. If process B later wants to use the file without the risk of it being modified externally, it would omit FILE_SHARE_WRITE<\/strong> when opening the file. IoCheckLinkShareAccess<\/strong> looks for open file handles, but since the handles were previously closed, it will not fail the operation.<\/p>\n
This creates a problem for file sharing. Process B thinks it has a file open without risk of external modification, but process A can modify it through the memory mapping. To account for this, the filesystem must also call MmDoesFileHaveUserWritableReferences<\/strong><\/a>. This checks whether there are any active writable file mappings to the given file. We can see this check in the FastFAT example here<\/a>:<\/p>\n
\/\/\n\/\/ Do an extra test for writeable user sections if the user did not allow\n\/\/ write sharing - this is neccessary since a section may exist with no handles\n\/\/ open to the file its based against.\n\/\/ if ((NodeType( FcbOrDcb ) == FAT_NTC_FCB) && !FlagOn( ShareAccess, FILE_SHARE_WRITE ) && FlagOn( *DesiredAccess, FILE_EXECUTE | FILE_READ_DATA | FILE_WRITE_DATA | FILE_APPEND_DATA | DELETE | MAXIMUM_ALLOWED ) && MmDoesFileHaveUserWritableReferences( &FcbOrDcb->NonPaged->SectionObjectPointers )) { return STATUS_SHARING_VIOLATION;\n}<\/code><\/pre>\n
Windows requires PE files to be immutable (unmodifiable) while they are running. This prevents EXEs and DLLs from being changed on disk while they are running in memory. Filesystem drivers must use the MmFlushImageSection<\/strong><\/a> function to check whether there are any active image mappings of a PE before allowing FILE_WRITE_DATA<\/strong> access. We can see this in the FastFAT example code<\/a>, and on Microsoft Learn<\/a>.<\/p>\n
\/\/\n\/\/ If the user wants write access access to the file make sure there\n\/\/ is not a process mapping this file as an image. Any attempt to\n\/\/ delete the file will be stopped in fileinfo.c\n\/\/\n\/\/ If the user wants to delete on close, we must check at this\n\/\/ point though.\n\/\/ if (FlagOn(*DesiredAccess, FILE_WRITE_DATA) || DeleteOnClose) { Fcb->OpenCount += 1; DecrementFcbOpenCount = TRUE; if (!MmFlushImageSection( &Fcb->NonPaged->SectionObjectPointers, MmFlushForWrite )) { Iosb.Status = DeleteOnClose ? STATUS_CANNOT_DELETE : STATUS_SHARING_VIOLATION; try_return( Iosb ); }\n}<\/code><\/pre>\n
Another way to think of this check is that ZwMapViewOfSection(SEC_IMAGE)<\/strong> implies no-write-sharing as long as the view exists.<\/p>\n
The Windows Authenticode Specification<\/a> describes a way to employ cryptography to \u201csign\u201d PE files. A \u201cdigital signature\u201d cryptographically attests that the PE was produced by a particular entity. Digital signatures are tamper-evident, meaning that any material modification of signed files should be detectable because the digital signature will no longer match. Digital signatures are typically appended to the end of PE files.<\/p>\n
\"Authenticode
Authenticode specification diagram showing a signature embedded within a PE<\/figcaption><\/figure>\n
Authenticode can\u2019t apply traditional hashing (e.g. sha256sum<\/strong>) in this case, because the act of appending the signature would change the file\u2019s hash, breaking the signature it just generated. Instead, the Authenticode specification describes an algorithm to skip specific portions of the PE file that will be changed during the signing process. This algorithm is called authentihash<\/strong>. You can use authentihash with any hashing algorithm, such as SHA256. When a PE file is digitally signed, the file\u2019s authentihash is what\u2019s actually signed.<\/p>\n
<\/span>Code integrity<\/h2>\n
Windows has a few different ways to validate Authenticode signatures. User mode applications can call WinVerifyTrust<\/strong><\/a> to validate a file\u2019s signature in user mode. The Code Integrity (CI) subsystem, residing in ci.dll<\/code>, validates signatures in the kernel. If Hypervisor-Protected Code Integrity<\/a> is running, the Secure Kernel employs skci.dll<\/code> to validate Authenticode. This article will focus on Code Integrity (ci.dll<\/code>) in the regular kernel.<\/p>\n
Code Integrity provides both Kernel Mode Code Integrity and User Mode Code Integrity, each serving a different set of functions.<\/p>\n
Kernel Mode Code Integrity (KMCI):<\/p>\n
User Mode Code Integrity (UMCI):<\/p>\n
KMCI and UMCI implement different policies for different scenarios. For example, the policy for Protected Processes is different from that of INTEGRITYCHECK.<\/p>\n
Microsoft documentation<\/a> implies that files successfully opened without write sharing can\u2019t be modified by another user or process.<\/p>\n
FILE_SHARE_WRITE\n0x00000002\nEnables subsequent open operations on a file or device to request write access. Otherwise, other processes cannot open the file or device if they request write access.<\/code><\/pre>\n
If this flag is not specified, but the file or device has been opened for write access or has a file mapping with write access, the function fails.<\/p>\n
Above, we discussed how sharing is enforced by the filesystem, but what if the filesystem doesn\u2019t know that the file\u2019s been modified?<\/em><\/p>\n
Like most user mode memory, the Memory Manager (MM) in the kernel may page-out portions of file mappings when it deems necessary, such as when the system needs more free physical memory. Both data and executable image mappings may be paged-out. Executable image sections can never modify the backing file, so they\u2019re effectively treated as read-only with respect to the backing PE file. As mentioned before, image sections are copy-on-write, meaning any in-memory changes immediately create a private copy of the given page.<\/p>\n
When the memory manager needs to page-out a page from an image section, it can use the following decision tree:<\/p>\n