AOH :: HP Unsorted G :: VA1506.HTM

GearSoftware Powered Products Local Privilege Escalation
GearSoftware Powered Products Local Privilege Escalation (Microsoft Windows Kernel IopfCompleteRequest Integer Overflow)
GearSoftware Powered Products Local Privilege Escalation (Microsoft Windows Kernel IopfCompleteRequest Integer Overflow)

[ HTML FORMATED Advisory ] 


 GearSoftware Powered Products Local Privilege Escalation
+ GEARASpiWDM.sys Insecure Method
+ Microsoft Windows Kernel IopfCompleteRequest Integer Overflow

:: Summary

   1. Background
   2. Non-technical description
   3. Technical Description
   4. Exploiting it
   5. References
   6. Affected Products
   7. Credits
   8. Disclosure Timeline
   9. Contact

            1. Background

"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" 

            2. Non-technical description

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.

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:

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.

            3.  Technical Description.

The problem lies in how the stack locations are traversed while  trying
to complete an IRP. Let's see

lkd> dt nt!_IRP


   +0x022 StackCount       : Char                   *signed*

   +0x023 CurrentLocation  : Char                *signed*


Module: ntoskrnl.exe

Version: XP SP2


.text:0040CC01 ; __fastcall IopfCompleteRequest(x, x)

.text:0040CC01 @IopfCompleteRequest@8 proc near        ; CODE XREF:

.text:0040CC01                             ;
IoPerfCompleteRequest(x,x)+B8p ...


.text:0040CC01 var_C           = dword ptr -0Ch

.text:0040CC01 var_8           = dword ptr -8

.text:0040CC01 var_1           = byte ptr -1



.text:0040CC01      mov     edi, edi

.text:0040CC03      push    ebp

.text:0040CC04      mov     ebp, esp

.text:0040CC06      sub     esp, 10h

.text:0040CC09      push    ebx

.text:0040CC0A      push    esi

.text:0040CC0B      mov     esi, ecx

.text:0040CC0D      mov     cl, [esi+23h]   ; Irp->CurrentLocation

.text:0040CC10      mov     [ebp+var_8], edx

.text:0040CC13      mov     dl, [esi+22h]   ; Irp->StackCount

.text:0040CC16      xor     ebx, ebx

.text:0040CC18      inc     dl              ; Irp->StackCount+1

.text:0040CC1A      cmp     cl, dl

.text:0040CC1C      push    edi

.text:0040CC1D      mov     [ebp+var_C], ebx

.text:0040CC20      jg      sub_444F81

.text:0040CC26      cmp     word ptr [esi], 6 ; Irp->Type == IO_TYPE_IRP

.text:0040CC2A      jnz     sub_444F81

.text:0040CC30      mov     edi, [esi+60h]  ; Irp->CurrentStackLocation

.text:0040CC33      inc     cl

.text:0040CC35      cmp     cl, dl

.text:0040CC37      lea     eax, [edi+24h]

.text:0040CC3A      mov     [esi+23h], cl  ; Irp->CurrentLocation++

.text:0040CC3D      mov     [esi+60h], eax

.text:0040CC40      jg      short loc_40CCA6

.text:0040CC42      add     edi, 3



.text:0040CC8D loc_40CC8D:    ; CODE XREF: IopfCompleteRequest(x,x)+13Cj

.text:0040CC8D      add     dword ptr [esi+60h], 24h ; StackLocation++

.text:0040CC91      mov     eax, [esi+60h]

.text:0040CC94      add     edi, 24h

.text:0040CC97      inc     byte ptr [esi+23h] ; Irp->CurrentLocation++

.text:0040CC9A      mov     dl, [esi+22h]   ; Irp->StackCount

.text:0040CC9D      mov     cl, [esi+23h]   ; Irp->CurrentLocation

.text:0040CCA0      inc     dl

.text:0040CCA2      cmp     cl, dl   ; if CurrentLocation <= StackCount+1

.text:0040CCA4      jle     short loc_40CC45  ; Signed comparison  - FLAW -

pStack = IoGetCurrentIrpStackLocation( Irp )

for(     pStack,



            Irp->CurrentLocation <= (CHAR) (Irp->StackCount + 1);



            Irp->CurrentLocation++ )




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

            4. 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:

.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++


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"

+         "\\.\GEARAspiWDMDevice"

The flaw lies within the handler for the IOCTL = = 0x222020

Module: GEARspiWDM.sys

.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:

.text:00011D10                 push    eax             ; DeviceObject

.text:00011D11                 call    sub_11B90


Module: GEARspiWDM.sys

.text:00011B90 ; int __stdcall sub_11B90(PDEVICE_OBJECT DeviceObject)

.text:00011B90 sub_11B90       proc near               ; CODE XREF:


.text:00011B90 TargetDevice    = UNICODE_STRING ptr -10h

.text:00011B90 var_8           = dword ptr -8

.text:00011B90 var_4           = dword ptr -4

.text:00011B90 DeviceObject    = dword ptr  8


.text:00011B90                 push    ebp

.text:00011B91                 mov     ebp, esp

.text:00011B93                 sub     esp, 10h

.text:00011B96                 mov     eax, [ebp+DeviceObject]

.text:00011B99                 mov     eax, [eax+3Ch]

.text:00011B9C                 push    ebx

.text:00011B9D                 xor     ebx, ebx

.text:00011B9F                 cmp     eax, ebx

.text:00011BA1                 push    edi

.text:00011BA2                 mov     edi, ecx

.text:00011BA4                 mov     [ebp+var_8], eax

.text:00011BA7                 mov     [ebp+DeviceObject], ebx

.text:00011BAA                 jnz     short loc_11BB6

.text:00011BAC                 mov     eax, 0C000000Dh

.text:00011BB1                 jmp     loc_11C9C

.text:00011BB6 ;


.text:00011BB6 loc_11BB6:                              ; CODE XREF:

.text:00011BB6                 push    eax             ; SourceString

.text:00011BB7                 lea     eax, [ebp+TargetDevice]

.text:00011BBA                 push    eax             ; DestinationString

.text:00011BBB                 call    ds:RtlInitUnicodeString


.text:00011C3E                 lea     edi, [esi+10h]

.text:00011C41                 push    edi             ; AttachedDevice

.text:00011C42                 lea     eax, [ebp+TargetDevice]

.text:00011C45                 push    eax     ; TargetDevice ;

.text:00011C46                 push    [ebp+DeviceObject] ; SourceDevice

.text:00011C49                 call    ds:IoAttachDevice

            5.  References

            GearSoftware Updated Drivers: 




            6. Affected Products

Vulnerable Version

 < 2.011.2  (32-bit)      <  (64-bit)

Microsoft Windows Kernel All versions 32/64-bit + 2000 + 2003 + XP + Vista

Apple iTunes 7.x

Symantec Norton 360  2.0 and earlier

Symantec Norton Ghost 14.0 and earlier

Symantec Norton Save and Restore 2.0 and earlier

Symantec Backup Exec System Recovery 6.x, 7.x and 8.x

            7.  Credits

            Vulnerability discovered and researched by Ruben Santamarta,

            8.  Disclosure Timeline

11/14/2007 - Microsoft Contacted

12/26/2007 - Symantec Contacted

12/26/2007 - Apple Contacted

10/07/2008 - Coordinated Disclosure

            9.  Contact

Agustin de Betancourt, 21. 8th Floor.
28003 Madrid.


Phone: +(34) 91 395 63 40

contact (at) wintercore (dot) com   [email concealed] 


Agustin de Betancourt, 21. 8th Floor.
28003 Madrid. Spain.
Phone: +(34) 91 395 63 40 

The entire AOH site is optimized to look best in Firefox® 3 on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2015 AOH
We do not send spam. If you have received spam bearing an email address, please forward it with full headers to