EEYE: Microsoft RPC Heap Corruption Vulnerability - Part II

From: Marc Maiffret (marc_at_eeye.com)
Date: 09/10/03

  • Next message: Dan Harkless: "Re: Permitting recursion can allow spammers to steal name server resources"
    To: "BUGTRAQ" <BUGTRAQ@SECURITYFOCUS.COM>
    Date: Wed, 10 Sep 2003 10:32:40 -0700
    
    

    Microsoft RPC Heap Corruption Vulnerability - Part II

    Release Date:
    September 10, 2003

    Severity:
    High (Remote Code Execution)

    Systems Affected:
    Microsoft Windows NT Workstation 4.0
    Microsoft Windows NT Server 4.0
    Microsoft Windows NT Server 4.0, Terminal Server Edition
    Microsoft Windows 2000
    Microsoft Windows XP
    Microsoft Windows Server 2003

    Description:

    eEye Digital Security has discovered a critical remote vulnerability in the
    way Microsoft Windows handles certain RPC requests. The RPC (Remote
    Procedure Call) protocol provides an inter-process communication mechanism
    allowing a program running on one computer to execute code on a remote
    system.

    A vulnerability exists within the DCOM (Distributed Component Object Model)
    RPC interface. This interface handles DCOM object activation requests sent
    by client machines to the server.

    Note: this vulnerability differs from the vulnerability publicized in
    Microsoft Bulletin MS03-026.
    (http://www.microsoft.com/technet/security/bulletin/MS03-026.asp)
    This is a new vulnerability, and a different patch that must be installed.

    By sending a malformed request packet it is possible to overwrite various
    heap structures and allow the execution of arbitrary code.

    Technical Details:

    The vulnerability can be replicated with a DCERPC "bind" packet, followed by
    a malformed DCERPC DCOM object activation request packet. Issuing the API
    function CoGetInstanceFromFile can generate the required request. By
    manipulating the length fields within the activation packet, portions of
    heap memory can be overwritten with data which may be user-defined.

    Sending between 4 and 5 activation packets is generally sufficient to
    trigger the overwrite.

    Upon sending the sequence of packets we were able to continually cause an
    exception within the usual suspect RtlAllocateHeap:

    PAGE:77FC8F11 mov [ecx], eax
    PAGE:77FC8F13 mov [eax+4], ecx

    We control the values of the registers eax and ecx. We can write an
    arbitrary dword to any address of our choosing.

    Execution of code can be achieved through a number of means -- the
    unhandledexceptionfilter or a PEB locking pointer for instance. For this
    specific vulnerability the best route was to overwrite a pointer within the
    writeable .data section of RPCSS.DLL :

    .data:761BC254 off_761BC254 dd offset loc_761A1AE7 ; DATA XREF:
    sub_761A19EF+1C_r
    .data:761BC254 ; sub_761A19EF+11D_w
    ...
    .data:761BC258 off_761BC258 dd offset loc_761A1B18 ; DATA XREF:
    sub_761A19EF+108_w
    .data:761BC258 ; sub_761A1DCF+13_r
    ...

    At runtime these two pointers reference RtlAllocateHeap and RtlFreeHeap
    respectively. By overwriting offset 0x761BC258 with our chosen EIP value, we
    control the processor directly after the heap overwrite. The added benefit
    in choosing this pointer is we have data from our received packet at
    ebp->10h which we may modify to our liking, within reason. There is one
    small obstacle that must be overcome. The first word value at that address
    is the length field of our packet, this field must translate to an opcode
    sequence that will allow us to reach our data that follows.

    Protection:
    Retina Network Security Scanner has been updated to identify this
    vulnerability.
    http://www.eeye.com/html/Products/Retina/index.html
    Also our FREE RPC scanner tool has been updated to check for this second
    vulnerability.
    http://www.eeye.com/html/Research/Tools/RPCDCOM.html

    Vendor Status:
    Microsoft has released a patch for this vulnerability. The patch is
    available at:
    http://www.microsoft.com/technet/treeview/?url=/technet/security/bulletin/MS
    03-039.asp

    Credit:
    Discovery: Barnaby Jack
    Additional Research: Barnaby Jack and Riley Hassell.

    Greetings:
    Thanks to Riley, and utmost respect to all of the eEye massive - masters of
    the black arts.
    Greets to all the new people I met in Vegas this year, especially the NZ
    crew, and many thanks to K2 (da bankrolla.) :)
    "This is my line. This is eternal." -AFI

    Copyright (c) 1998-2003 eEye Digital Security
    Permission is hereby granted for the redistribution of this alert
    electronically. It is not to be edited in any way without express consent of
    eEye. If you wish to reprint the whole or any part of this alert in any
    other medium excluding electronic medium, please e-mail alert@eEye.com for
    permission.

    Disclaimer
    The information within this paper may change without notice. Use of this
    information constitutes acceptance for use in an AS IS condition. There are
    NO warranties with regard to this information. In no event shall the author
    be liable for any damages whatsoever arising out of or in connection with
    the use or spread of this information. Any use of this information is at the
    user's own risk.

    Feedback
    Please send suggestions, updates, and comments to:

    eEye Digital Security
    http://www.eEye.com
    info@eEye.com


  • Next message: Dan Harkless: "Re: Permitting recursion can allow spammers to steal name server resources"

    Relevant Pages