Vulnerability MS14-063 in the FastFat driver in Windows OS. Debriefing
In this study, we will analyze the MS14-063 vulnerability associated with 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 a long time ago, by the way, but this is a completely different story - this is described in more detail in an article on xakep.ru). Immediately we will talk about what opportunities this vulnerability could actually provide to an attacker who decided to implement an attack using a USB flash drive with a “bat” FS FAT.
So, let's start with a brief description of the FAT file system device — the operation with which the vulnerable fastfat.sys driver implements. Detailed documentation can be seen in the specification ( link ). We will only dwell on the provisions that interest us.
Illustration of building a FAT file system taken from c-jump.com ( link )
At the beginning of the volume (at zero offset) is the so-called Boot Sector (in fact, Parameter Block BIOS, or, in abbreviated form, BPB). This is a structure that describes the total volume device and is necessary for the volume to be properly handled 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 now is that we are talking specifically about the Fat32 file system, since in other implementations of FAT, the offsets in BPB will be different, and not only they.
')
Next, BPB is followed by the FAT structure itself (FAT Data Structure), which is essentially a single-linked list of file clusters (the entire disk is divided into clusters (and only one file can be in one cluster at a time)), the size of which is set during formatting disk - in turn, the clusters are divided into sectors)
Illustration of the device storage area information (Data Area) on disk, taken from the resource technet.microsoft.com ( link )
At this stage, you need to remember about BPB, but rather to pay attention to the field NumFats. According to the specification, this field sets the number of copies of the FAT structure for each file. In the same specification it is stated that the standard value (which, respectively, guarantees compatibility of the FS with different drivers) for this field is 2, i.e. For each file, there are 2 copies of the FAT structure - this is necessary to prevent the loss of the file 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 the code segment occurs that incorrectly allocates memory in the kernel pool (since the code is executed inside the driver).
Illustration of the section of the vulnerable code of the FatCommonWrite function of the fastfat.sys driver, taken from the blog.beyondtrust.com resource - a blog from BeyondTrust experts who also investigated this vulnerability ( link )
The vulnerability is in the FatCommonWrite function, or rather in the call to ExAllocatePoolWithTag, where the numfat value, the number of copies of the IoRuns structures not multiplied by their size, is passed as an argument to the required space. In the code shown in the illustration, the ecx register contains a pointer to the BPB structure, and at offset 96h from it is the NumFats field, which, as can be seen from the illustration, falls on the stack as an argument to NumberOfBytes for the ExAllocatePoolWithTag function (by the way, as a patch , released from Microsoft, is just the addition of the missing multiplication in the block shown in the illustration).
At this stage, it is worthwhile to talk more about the memory device of the drivers (a very good analysis of this class of vulnerabilities is on Habré - link ). Summarizing it, we have: the memory of the drivers is divided into Pool'y, each of which is a list of Chunk, in which, respectively, is the necessary information for the driver.
Thus, there is a vulnerability of the type kernel pool overflow in the memory area, and, as a result, it is possible to exploit it by interrupting the memory chunk of another driver that is in memory immediately after the overflowing chunk.
Illustration of the chunk overflow process, taken from the Habré article on Kernel Pool Overflow ( link )
At this stage, we have already achieved some result - we correlate the memory of another driver, which leads to BSOD with the 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 (immediately after the overflowed) chunk to the correct, but not valid, but arbitrary (in order to capture the driver’s memory flow). This will potentially lead to the fact that the attacker will be able to execute code on behalf of the driver, i.e. with privilege escalation. However, as the analysis of the data with which we overwhelm chunk has shown, there is no such possibility in this situation. To justify this, consider the structure of IoRuns, for which just allocated memory in a vulnerable function. Presumably (again, based on the Windows 2000 sources), the IoRuns structure serves as a tool used when writing FAT structures to the file system (since the FatCommonWrite function calls just when writing new files to disk, that is, creating / changing FAT -structures). The point is that all copies (their number is regulated by the NumFats field in BPB) are recorded asynchronously, for this each copy is assigned its own copy of IoRuns, which indicates which offset to write (Vbo and Lbo fields) and how much to write ( ByteCount).
Illustration of the initialization cycle of IoRuns structures (according to 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 uniquely calculated, from the values ​​of the fields of the first structure. What we have: the first field is the offset at which the recording of copies of FAT structures begins, the second field is the offset at which this copy is recorded (according to the writer's value), the third field is probably needed for processing an additional prolog to the FAT structure. And the last field is set directly from BPB - it is equal to the BPB_BytsPerSec field, since 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, since we control only one ULONG field, which leads to the conclusion that it is impossible to implement privilege escalation.
To summarize: this study leads to the question, are Microsoft experts right in saying that MS14-063 is really significant and can lead to escalation of privileges? According to the analysis, the possibility of “harming” this vulnerability is only available in the BSOD call, but there is no need to speak of any escalations.
So, let's start with a brief description of the FAT file system device — the operation with which the vulnerable fastfat.sys driver implements. Detailed documentation can be seen in the specification ( link ). We will only dwell on the provisions that interest us.
Illustration of building a FAT file system taken from c-jump.com ( link )
At the beginning of the volume (at zero offset) is the so-called Boot Sector (in fact, Parameter Block BIOS, or, in abbreviated form, BPB). This is a structure that describes the total volume device and is necessary for the volume to be properly handled 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 now is that we are talking specifically about the Fat32 file system, since in other implementations of FAT, the offsets in BPB will be different, and not only they.
')
Next, BPB is followed by the FAT structure itself (FAT Data Structure), which is essentially a single-linked list of file clusters (the entire disk is divided into clusters (and only one file can be in one cluster at a time)), the size of which is set during formatting disk - in turn, the clusters are divided into sectors)
Illustration of the device storage area information (Data Area) on disk, taken from the resource technet.microsoft.com ( link )
At this stage, you need to remember about BPB, but rather to pay attention to the field NumFats. According to the specification, this field sets the number of copies of the FAT structure for each file. In the same specification it is stated that the standard value (which, respectively, guarantees compatibility of the FS with different drivers) for this field is 2, i.e. For each file, there are 2 copies of the FAT structure - this is necessary to prevent the loss of the file 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 the code segment occurs that incorrectly allocates memory in the kernel pool (since the code is executed inside the driver).
Illustration of the section of the vulnerable code of the FatCommonWrite function of the fastfat.sys driver, taken from the blog.beyondtrust.com resource - a blog from BeyondTrust experts who also investigated this vulnerability ( link )
The vulnerability is in the FatCommonWrite function, or rather in the call to ExAllocatePoolWithTag, where the numfat value, the number of copies of the IoRuns structures not multiplied by their size, is passed as an argument to the required space. In the code shown in the illustration, the ecx register contains a pointer to the BPB structure, and at offset 96h from it is the NumFats field, which, as can be seen from the illustration, falls on the stack as an argument to NumberOfBytes for the ExAllocatePoolWithTag function (by the way, as a patch , released from Microsoft, is just the addition of the missing multiplication in the block shown in the illustration).
At this stage, it is worthwhile to talk more about the memory device of the drivers (a very good analysis of this class of vulnerabilities is on Habré - link ). Summarizing it, we have: the memory of the drivers is divided into Pool'y, each of which is a list of Chunk, in which, respectively, is the necessary information for the driver.
Thus, there is a vulnerability of the type kernel pool overflow in the memory area, and, as a result, it is possible to exploit it by interrupting the memory chunk of another driver that is in memory immediately after the overflowing chunk.
Illustration of the chunk overflow process, taken from the Habré article on Kernel Pool Overflow ( link )
At this stage, we have already achieved some result - we correlate the memory of another driver, which leads to BSOD with the 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 (immediately after the overflowed) chunk to the correct, but not valid, but arbitrary (in order to capture the driver’s memory flow). This will potentially lead to the fact that the attacker will be able to execute code on behalf of the driver, i.e. with privilege escalation. However, as the analysis of the data with which we overwhelm chunk has shown, there is no such possibility in this situation. To justify this, consider the structure of IoRuns, for which just allocated memory in a vulnerable function. Presumably (again, based on the Windows 2000 sources), the IoRuns structure serves as a tool used when writing FAT structures to the file system (since the FatCommonWrite function calls just when writing new files to disk, that is, creating / changing FAT -structures). The point is that all copies (their number is regulated by the NumFats field in BPB) are recorded asynchronously, for this each copy is assigned its own copy of IoRuns, which indicates which offset to write (Vbo and Lbo fields) and how much to write ( ByteCount).
Illustration of the initialization cycle of IoRuns structures (according to 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 uniquely calculated, from the values ​​of the fields of the first structure. What we have: the first field is the offset at which the recording of copies of FAT structures begins, the second field is the offset at which this copy is recorded (according to the writer's value), the third field is probably needed for processing an additional prolog to the FAT structure. And the last field is set directly from BPB - it is equal to the BPB_BytsPerSec field, since 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, since we control only one ULONG field, which leads to the conclusion that it is impossible to implement privilege escalation.
To summarize: this study leads to the question, are Microsoft experts right in saying that MS14-063 is really significant and can lead to escalation of privileges? According to the analysis, the possibility of “harming” this vulnerability is only available in the BSOD call, but there is no need to speak of any escalations.
Source: https://habr.com/ru/post/248089/
All Articles