bugtraq - Microsoft Windows XP/2003 Macrovision SecDrv.sys privilege escalation (0day)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <471695AB.5040000@reversemode.com>
Date: Thu, 18 Oct 2007 01:07:23 +0200
From: Reversemode <advisories@...ersemode.com>
To: Securityfocus <bugtraq@...urityfocus.com>
Subject: Microsoft Windows XP/2003 Macrovision SecDrv.sys privilege escalation
 (0day)

Hi,

Symantec researcher Elia Florip has warned, at the company's weblog
[1],of a 0day attack in Windows XP and 2003 that allows unprivileged
users to gain SYSTEM privileges via a buggy driver installed by default.

In his/her post, Elia brings us an important clue:"At the moment, it's
still not clear how the driver is used by Windows because this file does
not have the typical Microsoft file properties present in other Windows
system files". Such a file it is not common so looking for this sort of
.sys we come across a couple of them. One of those drivers is
*secdrv.sys*, which is developed by Macrovision as part of SafeDisc.
Mario Ballano (48bits.com) and I we have been taking a look at the
driver and quickly found this interesting piece of code.

.text:00015E2C                 cmp     [ebp+var_10], 0CA002813h
.text:00015E33                 jz      short loc_15E69

As you can see the IOCTL is METHOD_NEITHER which is a potential
vulnerability by itself (few drivers are correctly handling this
method). Let's see whether this time is different...

.text:00015ED9                 call    dword ptr [eax+10h] ; Internal
Dispatcher
.text:00015EDC                 mov     [ebp+var_1C], eax
.text:00015EDF                 cmp     [ebp+var_1C], 0Ah
.text:00015EE3                 jz      short loc_15EFC
.text:00015EE5                 mov     eax, [ebp+arg_4]
.text:00015EE8                 mov     dword ptr [eax], 0C0000001h
.text:00015EEE                 mov     eax, [ebp+arg_4]
.text:00015EF1                 and     dword ptr [eax+4], 0
.text:00015EF5                 mov     eax, 0C0000001h
.text:00015EFA                 jmp     short loc_15F21
.text:00015EFC ;
---------------------------------------------------------------------------
.text:00015EFC
.text:00015EFC loc_15EFC:                              ; CODE XREF:
sub_15E12+D1j
.text:00015EFC                 mov     ecx, [ebp+var_4]
.text:00015EFF                 mov     esi, [ebp+var_C]
.text:00015F02                 mov     eax, [ebp+arg_0]
.text:00015F05                 mov     edi, [eax+3Ch]  ; Input Buffer
.text:00015F08                 mov     eax, ecx        ; Inline memcpy
.text:00015F0A                 shr     ecx, 2
.text:00015F0D                 rep movsd
.text:00015F0F                 mov     ecx, eax
.text:00015F11                 and     ecx, 3
.text:00015F14                 rep movsb

No luck. As you can see the buffer supplied by the user is not properly
checked so you can overwrite any address you wish, even kernel
addresses. Anyway, this piece of code is not very comfortable for
developing the exploit since it is overwriting the same buffer that is
used as input vector. The ideal situation would be bytes being copied
from the input buffer into the output buffer. Surprise, surprise...

---------------------------------------------------------------------------
.text:00015EFC
.text:00015EFC loc_15EFC:                              ; CODE XREF:
sub_15E12+D1j
.text:00015EFC                 mov     ecx, [ebp+var_4]
.text:00015EFF                 mov     esi, [ebp+var_C] ; Input Buffer
.text:00015F02                 mov     eax, [ebp+arg_0]
.text:00015F05                 mov     edi, [eax+3Ch]  ; Output Buffer
(Irp->UserBuffer)
.text:00015F08                 mov     eax, ecx        ; Inline memcpy
.text:00015F0A                 shr     ecx, 2
.text:00015F0D                 rep movsd
.text:00015F0F                 mov     ecx, eax
.text:00015F11                 and     ecx, 3
.text:00015F14                 rep movsb

The first 4 DWORDs of the input buffer are copied into the output buffer
without any further validation. However,there is a restriction:
InputBuffer[1] should be a fixed value in order to reach this piece of
code. No problem. Take a look at the exploit code.

I've released a K-plugin for kartoffel that exploits this flaw on
Windows XP SP2 and 2003 (32-bit).

Download at http://kartoffel.reversemode.com/downloads.php.
*This K-plugin can only be used for personal study and research
purposes. Do not email me requesting shellcodes, customized exploit or
something like that*

References:

[1]http://www.symantec.com/enterprise/security_response/weblog/2007/10/privilege_escalation_exploit_i.html
[2]http://www.macrovision.com
[3]http://www.reversemode.com/index.php?option=com_mamblog&Itemid=15&task=show&action=view&id=43&Itemid=15
[4]http://blog.48bits.com/?p=172 (castilian)

Despite there is no patch available, at the momment, we are disclosing
this information since an exploit has been caught in the wild so we see
no reason to hide information that can be useful for administrators and
researchers.

Regards,
Rubén.