Wintercore comprises of experienced professionals who research and develop innovative solutions for the IT Security industry.
Wintercore
Advisory
Latest News
10th Feb See Artica+IceSphere in action.
2nd Feb BlackLeaf released.
2nd Feb [W02-0209] Kaspersky klim5.sys advisory.
7th Oct [W02-1008] :: Multiple Products Security Advisory
6th Oct Blog:: Happy pack #1. Vulnerability for sale.
6th Oct Blog:: Motorola Timbuktu data leaked
4th May Blog:: Toward a new generation of audio captchas
26th April Blog:: Things that shouldn't be there
24th April [W01-0408] :: Realtek Security Advisory
5th March Blog:: Breaking Gmail's Audio Captcha
12th February Artica Beta released
Wintercore, after an intesive research, has developed a fully proactive and automatic Anti-Phishing Engine for classification and detection tasks. Thanks to its Computer Vision Based Core, ARTICA, can detect...[+]
Wintercore Research:: Advisory W02-1008
GearSoftware Powered Products Local Privilege Escalation
+ GEARASpiWDM.sys Insecure Method+ Microsoft Windows Kernel IopfCompleteRequest Integer Overflow
:: Summary
- Background
- Non-technical description
- Technical Description
- Exploiting it
- References
- Affected Products
- Credits
- Disclosure Timeline
- 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: 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.
- The underlying vulnerability:
Microsoft Windows Kernel IopfCompleteRequest Integer Overflow.
- The Attack Vector:
GearAspiWDM.sys Insecure Method.
- 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 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
.text:0040CC01 ;
__fastcall IopfCompleteRequest(x, x)
.text:0040CC01
@IopfCompleteRequest@8 proc near
; CODE XREF: IoPerfCompleteRequest(x,x)+88p
.text:0040CC01 ;
IoPerfCompleteRequest(x,x)+B8p ...
.text:0040CC01
.text:0040CC01
var_C = dword
ptr -0Ch
.text:0040CC01
var_8 = dword
ptr -8
.text:0040CC01
var_1 = byte
ptr -1
.text:0040CC01
.text:0040CC01
.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
;Irp->Tail->Overlay.CurrentStackLocation++
.text:0040CC40 jg short loc_40CCA6
.text:0040CC42 add edi, 3
{...}
.text:0040CC8D
.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
;Irp->Tail.Overlay.CurrentStackLocation++
.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->Tail.Overlay.CurrentStackLocation++
Irp->CurrentLocation++;
Irp->CurrentLocation
<= (CHAR) (Irp->StackCount + 1);
pStack++,
Irp->Tail.Overlay.CurrentStackLocation++
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
locations.
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:
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
Module: GEARspiWDM.sys (32-bit)
.text:00011B90 ; int
__stdcall sub_11B90(PDEVICE_OBJECT DeviceObject)
.text:00011B90 sub_11B90 proc near ; CODE XREF:
sub_11CA2+6Fp
.text:00011B90
.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
.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
.text:00011BB6 loc_11BB6:
; CODE XREF:
sub_11B90+1Aj
.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 ; user-controlled
.text:00011C46 push [ebp+DeviceObject] ; SourceDevice
.text:00011C49 call ds:IoAttachDevice
5. References
GearSoftware Updated Drivers:
http://www.gearsoftware.com/support/drivers.cfm
KB-CERT:
http://www.kb.cert.org/vuls/id/146896
Symantec:
http://www.symantec.com/avcenter/security/Content/2008.10.07a.html
Apple:
http://support.apple.com/kb/HT3025
6. Affected Products
|
Product/File |
Vulnerable Version |
|
GearAspiWDM.sys |
< 2.011.2 (32-bit) < 2.008.2.1 (64-bit) |
|
Microsoft Windows Kernel |
All
versions 32/64-bit + 2000 +
2003 + XP + |
|
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 |
|
Symantec LiveState Recovery |
sustaining |
7. Credits
Vulnerability discovered and
researched by Ruben Santamarta, Wintercore.
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
Wintercore
Agustin de Betancourt, 21. 8th Floor.
28003
Phone: +(34) 91 395 63
40
contact (at) wintercore (dot) com [email concealed]
www.wintercore.com
C/ Isla de Salvora, 180. contat (at) wintercore (dot) com
28034 Coyado Villalba.
Spain. Please use our PGP key.
Phone: +(34) 91 849 98 89