CVE-2014-4115 Analysis: Malicious USB Disks Allow For Possible Whole System Control

One of the bulletins that was part of the October 2014 Patch Tuesday cycle was MS14-063 which fixed a vulnerability in the FAT32 disk partition driver that could allow for an attacker to gain administrator rights on affected systems, with only a USB disk with a specially modified file system. This vulnerability as also designated as CVE-2014-4115.

Why is this vulnerability unusual?

We pay close attention to file system drivers because these can be used to attack systems via USB drives. Consider the earlier Stuxnet vulnerability: that was spread using one vulnerability in Windows shortcuts to easily run Windows shell code; a second vulnerability was used to gain administrator rights. A vulnerability in the file system driver can be used to perform what would normally be two separate step in just one.

CVE-2014-4115 is found in the file system driver (FASTFAT.SYS) of Windows Vista, Server 2003, and Server 2008. This driver is responsible for handling fast FAT file systems (like FAT32). This vulnerabily can be triggered when handling boot sectors with a specific BIOS Parameter Block (BPB) in FAT32-formatted drives.

FAT32 is still commonly used today in USB flash disks. Because of this, a targeted attack can be carried out using this vulnerability. Suppose that a specially crafted USB disk somehow ends up plugged into the laptop of a senior executive or a PC in that company’s intranet. Those systems can than be controlled by outside actors and potentially used in targeted attacks.

Timely patching by system administrators would have reduced the risk of falling victim to this attack. Enterprise system administrators should also reconsider existing policies on the use of USB media within corporate networks.

What and where is the vulnerability?

As we noted earlier, the vulnerability is found in FASTFAT.SYS. Comparing the vulnerable version and the patched version, there is only one difference: the function FatCommonWrite().

Figure 1. Difference between original and patched FASTFAT.SYS

The second parameter (NumberOfBytes) is multiplied by 0×18 in the patched version when the ExAllocatePoolWithTag function is called.

The prototype of function ExAllocatePoolWithTag() is as follows

PVOID ExAllocatePoolWithTag( _In_ POOL_TYPE PoolType, _In_ SIZE_T NumberOfBytes, _In_ ULONG Tag );

The bug itself is very simple. The developer performed the wrong calculation on the size needed memory that is to be allocated: he forgot to multiply the number of structures by the size of a single instruction. This can lead to out-of-bounds heap write operations in the following instructions.

The pseudocode around the vulnerability could be described as follows:

NTSTATUS FatCommonWrite ( IN PIRP_CONTEXT IrpContext, IN PIRP Irp )

{
……
if (TypeOfOpen == VirtualVolumeFile)
{
….
ULONG Fat;
ULONG BytesPerFat;
IO_RUN StackIoRuns[2];
PIO_RUN IoRuns;
BytesPerFat = FatBytesPerFat( &Vcb->Bpb );
if ((ULONG)Vcb->Bpb.Fats > 2) {
IoRuns = FsRtlAllocatePoolWithTag(
PagedPool,
(ULONG)(Vcb->Bpb.Fats), //Actual vulnerability, missing ×sizeof(IO_RUN)
TAG_IO_RUNS );
} else
{
IoRuns = StackIoRuns;}
for (Fat = 0; Fat < (ULONG)Vcb->Bpb.Fats; Fat++)
{
IoRuns[Fat].Vbo = StartingDirtyVbo;
IoRuns[Fat].Lbo = Fat * BytesPerFat + StartingDirtyVbo;
IoRuns[Fat].Offset = StartingDirtyVbo – StartingVbo;
IoRuns[Fat].ByteCount = WriteLength;
}
……
}
……
}

Obviously, when Bpb.Fats is 3 or above, the memory allocation for IoRuns by FsRtlAllocatePoolWithTag() is less than the expected size. It would typically cause a crash when IoRuns is called again – for example, when it is initiated in the “for” statement. However, hackers can use it to overwrite some kernel objects deliberately, setting the stage for arbitrary code execution.

Triggering the vulnerability

Since any FAT32 file write request with the VirtualVolumeFile file type could trigger FatCommonWrite, the key point is how to control Vcb->Bpb.Fats to meet the condition (Vcb ->Bpb.Fats > 2) of the vulnerability

In the fastfat implementation, the Vcb (Volume control Block) record corresponds to every volume mounted by the file system. In FatCommonWrite, Vcb is initiated with FileObject which is the memory representation of FAT32 volume partition just before the vulnerability.

The Vcb trace back process for detail is shown below:

Figure 2. Vcb trace back

_USBSTOR is the volume label of our USB drive for test with FAT32 file system.

What is Bpb.Fats?

Usually, the MBR (Master Boot Record) is located in cylinder 0, head 0, sector 1, while the Boot Sector of the first partition of a FAT32 volume is located in cylinder 0, head 1, sector 1.

The first important data structure of a FAT volume is called the BPB (BIOS Parameter Block), which is located in the first sector (Boot Sector) of the volume in the Reserved Region.

Figure 3. BPB in disk format

The definition of a BPB’s structure can be found in Microsoft Windows Driver Kit as follows:

typedef struct BIOS_PARAMETER_BLOCK { USHORT BytesPerSector; UCHAR SectorsPerCluster; USHORT ReservedSectors; UCHAR Fats; //Number of FAT tables, default 2 USHORT RootEntries; USHORT Sectors; UCHAR Media; USHORT SectorsPerFat; USHORT SectorsPerTrack; USHORT Heads; ULONG32 HiddenSectors; ULONG32 LargeSectors; ULONG32 LargeSectorsPerFat; union { USHORT ExtendedFlags; struct { ULONG ActiveFat:4; ULONG Reserved0:3; ULONG MirrorDisabled:1; ULONG Reserved1:8; }; };

USHORT FsVersion; ULONG32 RootDirFirstCluster; USHORT FsInfoSector; USHORT BackupBootSector; } BIOS_PARAMETER_BLOCK, *PBIOS_PARAMETER_BLOCK;

How to control Bpb.Fat?

Bpb.Fat is located in the fixed byte of the disk drive, which can be modified directly by a sector read/write tool.

In this test, we use FAT32 template of a binary editor to find out the Bpb (i.e. BPB_FAT32 structure in Figure 4) structure and the Fat field (i.e. NumberOfFats in Figure 4).

Figure 4 FATS in Data Structure of BPB

Proof of Concept leading to a crash

We made a proof of concept by simply modifying the BPB of a FAT32 USB disk. We changed BPB_FAT32.NumberOfFATs to a number greather than 2 using the sector read/write tool.

A crash soon results after the following steps:

Insert this USB disk into any PC with a vulnerable FASTFAT.SYS version.
Perform any write operation on the disk (i.e. copy a file onto it.)

Conclusions

This vulnerability is present in older versions of Windows – Vista, Server 2003, and Server 2008. Newer versions like Windows 7, Windows 8, Server 2008 R2, and Server 2012 are not affected.

The patch for this vulnerability makes the code for the patched platform essentially identical to newer versions. We suppose that the vulnerability was introduced by human error during coding or during code merging. This indicates that more vulnerabilities or bugs could be found out by binary comparison between Windows 7 and other platforms for FASTFAT.SYS.

Exploits for this vulnerability has not yet been seen publicly to date. However, the appearance of exploits in the wild cannot be ruled out. Incidents like these highlight the need for improved patch management on the part of enterprises, as even vulnerabilities that do not immediately lead to the execution of code on affected systems can pose risks, as this analysis shows. In addition, network-based solutions like Deep Discovery can help reduce the risks from certain kinds of vulnerabilities.

Post from: Trendlabs Security Intelligence Blog – by Trend Micro

CVE-2014-4115 Analysis: Malicious USB Disks Allow For Possible Whole System Control