GearSoftware Powered Products Local Privilege Escalation (IopfCompleteRequest)
20 Oct. 2008
Summary
"GEAR Software has set the standard for professional DVD & CD recording software for more than twenty years. GEAR develops solutions for professional premastering, DVD editing and authoring, and is also a leading provider of development tools that enable software companies to integrate optical recording technology into their own products. GEAR technology is integrated into solutions from some of the world's most prominent technology organizations, including Apple, Symantec, Siemens, Kodak, Philips and Bosch, among many others". Microsoft Windows Kernel is prone to a local privilege escalation due to an integer overflow error within the IopfCompleteRequest function. This vulnerability may allow attackers to execute arbitrary code in the kernel context, thus allowing to escalate privileges to SYSTEM. However, the attack vector needed for taking advantage of this weakness has not been identified on a out-of-box Windows installation. Therefore, a third-party application is, so far, the unique possible attack vector to exploit this issue.
Vulnerable Systems:
* GearAspiWDM.sys versions prior to 2.011.2 (32-bit)
* GearAspiWDM.sys versions prior to 2.008.2.1 (64-bit)
* Microsoft Windows Kernel All versions 32/64-bit + 2000 + 2003 + XP + Vista
* Apple iTunes version 7.x
* Symantec Norton 360 version 2.0 and earlier
* Symantec Norton Ghost version 14.0 and earlier
* Symantec Norton Save and Restore version 2.0 and earlier
* Symantec Backup Exec System Recovery version 6.x
* Symantec Backup Exec System Recovery version 7.x
* Symantec Backup Exec System Recovery version 8.x
This advisory covers the attack vector found in a widely extended licensed application, GearSoftware Recording SDK, which was exposing the kernel flaw to user-mode attackers through one of its filter drivers: GEARAspiWDM.sys
Since this driver is a licensed solution, it is bundled with several well-known products. To clarify as much as possible this vulnerability, we should distinguish three different elements which make up the problem.
1. The underlying vulnerability: Microsoft Windows Kernel IopfCompleteRequest Integer Overflow.
2. The Attack Vector: GearAspiWDM.sys Insecure Method.
3. Vulnerable Products: Every GearSoftware powered product that is bundled with GEARAspiWDM.sys. (e.g Norton 360, Apple iTunes...)
Whilst the underlying vulnerability is, under our point of view, a real vulnerability, the Attack Vector may or may not be considered a vulnerability by itself. Note that if we supress the underlying vulnerability from the equation, then the attack vector turns out to be practically useless, however by patching only the attack vector we will always be facing the risk that another one comes to light. On the other hand, this fact is not impossible but seems very unlikely.
Microsoft, as the vendor affected by the underlying vulnerability, Apple and Symantec as Vulnerable Products were directly contacted . After verifying the details provided Microsoft did not consider this flaw elegible for a patch. Therefore,with the help of the US-CERT, Symantec, Apple, GearSoftware and Wintercore were coordinated during the process of resolving this issue by patching GEARAspiWDM.sys driver.
The final outcome is that the Attack Vector has been patched although the underlying vulnerability still remains unpatched.
Technical Description:
The problem lies in how the stack locations are traversed while trying to complete an IRP. Let's see
Well, let's imagine an IRP where the StackCount and CurrentLocation = = 0x7e (pretty unusual but possible indeed)
After the first iterate within the for(){...} , CurrentLocation will be 0x80 which is a negative value so Irp->CurrentLocation <= (CHAR) (Irp->StackCount+1) becomes TRUE. Hence, remaining iterations will be running out of allocated memory, traversing arbitrary and invalid stack locations.
Exploiting it:
Digging into the for{} loop we found out the following:
Module: ntoskrnl.exe XP SP2 (32-bit)
.text:0040CD30 loc_40CD30: ; CODE XREF: IopfCompleteRequest(x,x)+4B47j
.text:0040CD30 push dword ptr [edi+1Dh]
.text:0040CD33 push esi
.text:0040CD34 push eax
.text:0040CD35 call dword ptr [edi+19h]
.text:0040CD38 cmp eax, 0C0000016h
.text:0040CD3D jnz loc_40CC8D ; StackLocation++ pStack->CompletionRoutine(...)
We must note that once the flaw has been triggered the for{} is traversing invalid stack locations where *(edi+19h) points to undetermined memory. We also have to take into account the internals of the IO Manager where the memory allocated for the IRPs is zeroed. Therefore, it has been proven that by allocating user-mode memory at 0x0 we can control the function pointer dereferenced.
However, that's not always true since we may be traversing uninitialized memory that holds random values. For that cases, it is also possible to seed the memory by issuing FSCTL/IOCTL requests before triggering the flaw,thus we can assure a high reliability exploiting this flaw.
Anyway, the hardest task is to discover a suitable attack vector since you need to force a huge driver stack. The patched driver was found implementing an insecure method by which, an unlimited number of calls to IoAttachDevice (TargetDevice is also user-controlled) were available from user-land, simply by issuing an IOCTL request.Since GearspiWDM.sys is signed in Vista 64-bit, it is possible to bypass certain kernel restrictions by exploiting this issue sucessfully.
The driver's insecure method is exposed via the following "free-for-all" device:
+ "\\.\GEARAspiWDMDevice"
The flaw lies within the handler for the IOCTL = = 0x222020
Module: GEARspiWDM.sys (32-bit)
.text:000114B2 loc_114B2: ; CODE XREF: sub_1137E+7Bj
.text:000114B2 cmp [ebp+var_1], 0
.text:000114B6 jz short loc_114CC
.text:000114B8 cmp [edi+54h], ecx
.text:000114BB jz short loc_114CC
.text:000114BD push ebx
.text:000114BE mov ecx, edi
.text:000114C0 call sub_11CA2 ; IRP_MJ_DEVICE_CONTROL Dispatch Routine
{...}
.text:00011CA2 mov eax, [esp+arg_0]
.text:00011CA6 mov edx, [eax+60h]
.text:00011CA9 mov edx, [edx+0Ch]
.text:00011CAC push esi
.text:00011CAD mov esi, 222010h
.text:00011CB2 cmp edx, esi
.text:00011CB4 ja short loc_11CF7
.text:00011CB6 jz short loc_11CEF
.text:00011CB8 sub edx, 222000h
.text:00011CBE jz short loc_11CE7
{...}
.text:00011D10 loc_11D10: ; CODE XREF: sub_11CA2+65j
.text:00011D10 push eax ; DeviceObject
.text:00011D11 call sub_11B90
||
\/
