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: <44F47807.3050104@cybsec.com>
Date: Tue, 29 Aug 2006 14:23:19 -0300
From: Mariano Nuñez Di Croce <mnunez@...sec.com>
To: bugtraq@...urityfocus.com
Subject: CYBSEC - Security Advisory: Microsoft Windows DHCP Client Service
 Remote Buffer Overflow

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(The following advisory is also available in PDF format for download at:
http://www.cybsec.com/vuln/CYBSEC-Security_Pre-Advisory_Microsoft_Windows_DHCP_Client_Service_Remote_Buffer_Overflow.pdf)

This advisory contains the full-detailed information regarding the vulnerability described in "CYBSEC Security Pre-Advisory: Microsoft Windows DHCP Client Service Remote Buffer Overflow".

CYBSEC S.A.
www.cybsec.com

Advisory Name: Microsoft Windows DHCP Client Service Remote Buffer Overflow
==============

Vulnerability Class: Stack Buffer Overflow
====================

Release Date: 08/29/2006
=============

Affected Platforms:
===================
* Microsoft Windows 2000 (<= SP4)
* Microsoft Windows XP (<= SP2)
* Microsoft Windows 2003 (<= SP1)

Local / Remote: Remote
===============

Severity: High
=========

Author:  Mariano Nuñez Di Croce
=======

Vendor Status:
==============
* Confirmed, update released.

Reference to Vulnerability Disclosure Policy:
=============================================
http://www.cybsec.com/vulnerability_policy.pdf


Vulnerability Description:
==========================

A remote buffer overflow vulnerability has been identified in Microsoft Windows DHCP-Client Service.


Technical Details:
==================

The vulnerability specifically exists in the way the dhcpcsvc.dll system library processes DHCP messages.

To extend the limit of 255 bytes defined by the length octet of the DHCP Option Field, Microsoft uses the private Option Code 0xFA (250), allowing the use of larger option values.

Therefore, a client trying to obtain its IP information may receive a DHCPACK packet with the following structure defined, after the MAGIC_COOKIE:

- -------------------------------------
2F FF [255 bytes] FA 09 [8 bytes] 00
- -------------------------------------

In the packet previously described, a NetBIOS over TCP/IP Scope option is being used, consisting of 264 bytes (including the NULL), effectively extending the limit of 255 bytes per Option.

The use of this Private Option Code is not restricted to be used only once after a known Option Code, so the following structure can also be used:

- -------------------------------------------------------------------------------
2F FF [255 bytes] FA FF [255 bytes] FA FF [255 bytes] ... FA FF [254 bytes] 00
- -------------------------------------------------------------------------------

Option Code 0x2F (NetBIOS over TCP/IP Scope ) was used for our internal proof-of-concept but other Option Codes can also be used.

Once the client receives this DHCPACK message, an option-reassembling process is undertaken so that intermediate "0xFA"s and Length octets are removed.
In this state the requesting client has an N bytes (N > 255) valid DHCP option value, which will now be saved in the stack, after trying to perform a Unicode translation process (Windows 2000):

In function DhcpRegSaveOptionAtLocation 2516 bytes of stack space is reserved:

- ---------------------------
55             PUSH EBP
8BEC           MOV EBP,ESP
81EC D4090000  SUB ESP,9D4
- ---------------------------

Then, the function DhcpOemToUnicode is called with the following arguments:

- ---------------------------------------------------------------------------------
8D85 2CF6FFFF  LEA EAX, DWORD PTR SS:[EBP-9D4]	
50             PUSH EAX            	; PUNICODE_STRING destination buffer
56             PUSH ESI	; POEM_STRING buffer received
E8 3E010000    CALL DhcpOemToUnicode
- ---------------------------------------------------------------------------------


In this function some values are calculated and passed to the DhcpOemToUnicodeN function:

- ----------------------------------------------------------------------------------
0FB745 F8      MOVZX EAX,WORD PTR SS:[EBP-8]	; POEM_STRING->Length
8D4400 02      LEA EAX,DWORD PTR DS:[EAX+EAX+2]	; LEN = (POEM_STRING->Length+1)*2
50             PUSH EAX
FF75 0C        PUSH DWORD PTR SS:[EBP+C]    	; PUNICODE_STRING buffer
FF75 08        PUSH DWORD PTR SS:[EBP+8] 	; POEM_STRING buffer
E8 04000000    CALL DhcpOemToUnicodeN
- ----------------------------------------------------------------------------------


In DhcpOemToUnicodeN, the following code is executed:

- -----------------------------------------------------------------------------------
8B45 10	MOX EAX,DWORD PTR SS:[EBP+10] ; Argument 3 (LEN)
8B75 0C	MOV ESI,DWORD PRT SS:[EBP+C]  ; PUNICODE_STRING->MaxLength
03C0	ADD EAX, EAX
85F6	TEST ESI,ESI
66:8945 FA	MOV WORD PTR SS:[EBP-6], EAX  ; PUNICODE_STRING->MaxLength = LEN*2
- -----------------------------------------------------------------------------------

As can be seen, the MaximumLength member of the UNICODE_STRING structure is calculated based on the length of the OEM string provided (which, by the way, has already been multiplied by two).

Finally, the following call to ntdll.RtlOemStringToUnicodeString is made:

- --------------------------------------------------------------------------
8D45 F0        LEA EAX,DWORD PTR SS:[EBP-10]	; POEM_STRING
6A 00          PUSH 0				; 0 = Do NOT Allocate
50             PUSH EAX
8D45 F8        LEA EAX,DWORD PTR SS:[EBP-8]	; PUNICODE_STRING
50             PUSH EAX
FF15 54103477  CALL ntdll.RtlOemStringToUnicodeString
- --------------------------------------------------------------------------

The call to ntdll.RtlOemStringToUnicodeString specifies that the buffer is already allocated by the caller. Therefore, this function will simply translate the supplied POEM_STRING->Buffer, storing the
resulting characters in
PUNICODE_STRING->Buffer, having done no bound checking.

This introduces the possibility of overflowing the stack space reserved for this buffer and gain control of execution modifying the SEH handler.

Impact:
=======
The dhcpcsvc.dll is loaded by services.exe in Windows 2000 and by svchost.exe in Windows XP/2003. As both these services run with SYSTEM privileges, an exploitation of this issue would allow Remote
Code Execution as SYSTEM over vulnerable systems.

Solutions:
==========
Microsoft has referred this vulnerability as MS06-036 and developed a patch to address it. Users should upgrade their system through Microsoft Windows Update facility.
More information can be found in Microsoft KB914388.

Vendor Response:
================
* 12/26/2005: Initial Vendor Contact.
* 01/19/2006: Vendor Confirmed Vulnerability.
* 07/11/2006: Vendor Releases Update.
* 07/11/2006: Pre-Advisory Public Disclosure.
* 08/29/2006: Advisory Public Disclosure.

Thanks:
=======
Special thanks go to Andres Riancho.

Contact Information:
====================
For more information regarding the vulnerability feel free to contact
the author at mnunez {at} cybsec.com.

For more information regarding CYBSEC: www.cybsec.com
(c) 2006 - CYBSEC S.A. Security Systems
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFE9HgHbbZGNCayCJkRAkSLAJ9vyk8CkGFXpg6BrgAEtWTU7IhFmQCfSWoU
7XDCfy+qUNTY2u3EBvVZYG4=
=YZsO
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ