Search This Blog

Thursday, October 18, 2007

[NT] Microsoft Windows XP/2003 Macrovision SecDrv.sys Privilege Escalation

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html


- - - - - - - - -

Microsoft Windows XP/2003 Macrovision SecDrv.sys Privilege Escalation
------------------------------------------------------------------------


SUMMARY

Symantec researcher Elia Florip has warned, at the company's weblog of a
0day attack in Windows XP and 2003 that allows unprivileged users to gain
SYSTEM privileges via a buggy driver installed by default. The following
advisory sheds light on the issue and reveals where the problem is.

DETAILS

In Elia Florip's 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.

Reversemode has 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>

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> http://www.symantec.com/enterprise/security_response/weblog/2007/10/privilege_escalation_exploit_i.html
[2] <http://www.macrovision.com> http://www.macrovision.com
[3]
<http://www.reversemode.com/index.php?option=com_mamblog&Itemid=15&task=show&action=view&id=43&Itemid=15> 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> http://blog.48bits.com/?p=172

(castilian)

Despite there is no patch available, at the moment, 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.


ADDITIONAL INFORMATION

The information has been provided by <mailto:advisories@reversemode.com>
Reversemode.
The original article can be found at:
<http://www.reversemode.com/index.php?option=com_mamblog&Itemid=15&task=show&action=view&id=43&Itemid=15> http://www.reversemode.com/index.php?option=com_mamblog&Itemid=15&task=show&action=view&id=43&Itemid=15

========================================


This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com


====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

No comments: