Vulnerability MS14-063 in FastFat driver in Windows OS. Debriefing

In this study, we analyze the vulnerability MS14-063 associated with the incorrect operation of the fastfat.sys driver and leading (at least, according to Microsoft) to unauthorized privilege escalation. Until recently, Win Server 2003/2008 and Win Vista were affected by this vulnerability (in Win7, this hole was fixed long ago, by the way, but this is a completely different story - this is described in more detail in the article on the resource). Here we will talk about what opportunities this vulnerability could actually provide to an attacker who decided to implement an attack using a flash drive with a “bat” FS FAT.

So, let's start with a brief description of the FAT file system device - working with which the vulnerable fastfat.sys driver implements. Detailed documentation can be seen in the specification ( link ). We will only dwell on the provisions of interest to us.

Illustration of building the FAT file system taken from ( link )

At the beginning of the volume (at zero offset) is the so-called Boot Sector (actually the BIOS Parameter Block, or, in short, BPB). This is a structure that describes the general structure of the volume and is necessary for the volume to be correctly processed by the driver. There are many useful fields in this structure, and we will return to some of them. The main thing that is worth noting right now is that we are talking specifically about the Fat32 file system, because in other FAT implementations, biases in the BPB will be different, and not only them.

Next, BPB is followed by the FAT itself (FAT Data Structure), which is essentially a single-linked list of file clusters (the entire disk is divided into clusters (moreover, only one file can contain data in one cluster at a time), the size of which is set during formatting disk - in turn, clusters are divided into sectors)

Illustration of the device of the Data Area on the disk, taken from the resource ( link )

At this stage, you need to remember about BPB, or rather pay attention to the NumFats field. According to the specification, this field sets the number of copies of the FAT structure for each file. The same specification states that the standard value (which, accordingly, guarantees FS compatibility with various drivers) for this field is 2, i.e. for each file there are 2 copies of the FAT structure - this is necessary to prevent file loss in case of bad sectors. It is in the processing of this field that the vulnerability lies. In the case when numfat> 2, a conditional transition to a section of code occurs that incorrectly allocates memory in the kernel pool (because the code is executed inside the driver).

An illustration of a portion of the vulnerable code of the FatCommonWrite function of the fastfat.sys driver taken from the resource, a blog of specialists from BeyondTrust who also investigated this vulnerability ( link )

The vulnerability is in the FatCommonWrite function, or rather, in the call to ExAllocatePoolWithTag, where as an argument - the required place is passed the value numfat - the number of copies of IoRuns structures not multiplied by their size. In the code shown in the illustration, in the ecx register there is a pointer to the BPB structure, and at offset 96h from it is the NumFats field, which, as can be seen from the illustration, gets on the stack as the NumberOfBytes argument of the ExAllocatePoolWithTag function (by the way, as a patch , released from Microsoft, is just adding the missing multiplication in the block shown in the illustration).

At this stage, worth more to talk about a memory device driver (a very good analysis of this class of vulnerabilities have Habre - link) Summarizing it, we have: the driver memory is divided into Pools, each of which is a list of Chunk, in which, accordingly, the information necessary for the driver lies.

Thus, there is a vulnerability like kernel pool overflow in the memory area, and, as a result, there is a possibility of its exploitation by interrupting the memory chunk of another driver, which lies in memory immediately after the overflowing chunk.

Illustration of the chunk overflow process, taken an article on the hub about Kernel Pool Overflow ( link )

At this stage, we have already achieved some result - we will corrupt the memory of another driver, which leads to a BSOD with a Bad Pool Header error. But this is not enough, because Memory Corruption is far from privilege escalation.

Our goal is to change the header of the attacked (lying immediately overflowing) chunk to the correct one, but not valid, but arbitrary (in order to capture the driver’s memory stream). This will potentially lead to the attacker having the opportunity to execute code on behalf of the driver, i.e. with privilege escalation. However, as the analysis of the data with which we overwhelm the chunk has shown, there is no such possibility in this situation. To justify this, consider the IoRuns structure, for which memory is allocated in a vulnerable function. Presumably (again, based on the sources of Windows 2000), the IoRuns structure serves as a tool used to write FAT structures to the file system (because the FatCommonWrite function calls just when new files are written to disk, i.e. creating / changing FAT structures). The point is

Illustration of the initialization cycle of IoRuns structures (according to the sources from WDK 8.0 Samples)

Thus, the values ​​in the fields of IoRuns structures are not so easy to replace, and all other structures will depend, or rather, be unambiguously calculated, from the values ​​of the fields of the first structure. What we have: the first field is the offset at which copies of FAT structures begin to be recorded, the second field is the offset at which this copy is recorded (according to the value of the writer), the third field is probably needed to process an additional prolog to the FAT structure. And the last field is set directly from BPB - it is equal to the field BPB_BytsPerSec, because Each copy of the FAT structure occupies one sector.

It follows that to set such data that will overwrite the next chunk and leave it correct is simply impossible, because we control only one ULONG field, which leads to the conclusion that it is impossible to implement privilege escalation.

To summarize: this study raises the question of whether Microsoft experts are right when they say that MS14-063 is really significant and can lead to an escalation of privileges? According to the analysis, the vulnerability is possible only in the BSOD call for this vulnerability, but there is no need to talk about any escalations.

Also popular now: