[NT] SetWindowLong Shatter Attacks

From: SecuriTeam (support_at_securiteam.com)
Date: 10/17/04

  • Next message: SecuriTeam: "[NT] Limited \secure\ buffer-overflow in some old Monolith games" 
    To: list@securiteam.com
Date: 17 Oct 2004 16:19:46 +0200

    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

    - - - - - - - - -

      SetWindowLong Shatter Attacks
    ------------------------------------------------------------------------

    SUMMARY

    The Windows SetWindowLong and SetWindowLongPtr API function calls can be
    used to exploit Windows applications to various degrees. The degree of
    exploitation is highly dependant upon the application itself.

    DETAILS

    Vulnerable Systems:
     * Microsoft Windows 98, 98SE, ME
     * Microsoft Windows NT 4.0
     * Microsoft Windows 2000 Service Pack 4
     * Microsoft Windows XP, Microsoft Windows XP Service Pack 1
     * Microsoft Windows Server 2003

    The SetWindowLong function changes an attribute of the specified window.
    The function also sets a 32-bit (long) value at the specified offset into
    the extra window memory of a window. The function prototype is as follows:

    LONG SetWindowLong(
      HWND hWnd, // handle of window
      int nIndex, // offset of value to set
      LONG dwNewLong // new value
    );

    Parameters:
    hWnd
      Handle to the window and, indirectly, the class to which the window
      belongs.
    nIndex
      Specifies the zero-based offset to the value to be set. Valid values
      are in the range zero through the number of bytes of extra window
      memory, minus 4; for example, if you specified 12 or more bytes of
      extra memory, a value of 8 would be an index to the third 32-bit
    integer.
      To set any other value, specify one of the following values:
      Value Action
      GWL_EXSTYLE Sets a new extended window style.
      GWL_STYLE Sets a new window style.
      GWL_WNDPROC Sets a new address for the window procedure.
      GWL_HINSTANCE Sets a new application instance handle.
      GWL_ID Sets a new identifier of the window.
      GWL_USERDATA Sets the 32-bit value associated with the window. Each
                     window has a corresponding 32-bit value intended for use
                     by the application that created the window.

    The following values are also available when the hWnd parameter identifies
    a dialog box:
      Value Action
      DWL_DLGPROC Sets the new address of the dialog box procedure.
      DWL_MSGRESULT Sets the return value of a message processed in the
                     dialog box procedure.
      DWL_USER Sets new extra information that is private to the
                     application, such as handles or pointers.

    dwNewLong
      Specifies the replacement value.

    Remarks
      The SetWindowLong function fails if the window specified by the hWnd
      parameter does not belong to the same process as the calling thread.

    As with the SendMessage() function (as used by standard shatter attacks)
    any user can call the SetWindowLong() function to alter the data stored in
    the window memory.

    Multiple third party and core windows services have been found that used
    the memory space pointed to by the GWL_USERDATA, to store specific data.
    In some cases this data could be manipulated to gain execution control.
    Since each application stores different information in this memory, the
    degree of danger is highly dependant on the application itself. An example
    of how execution control could be obtained will be shown below.

    A certain service that did not normally have a window, could be enticed
    into generating an error that would display a window. The service stored a
    pointer to a lookup table in the window memory pointed to by GWL_USERDATA.
    This lookup table held the address of functions, and was later used to
    retrieve an address and pass it to a CALL instruction.

    By using the process mapped heap, as explained in Brett Moore's Blackhat
    presentation, it was possible to place our shellcode into a known
    location. We could also
    construct a new lookup table, pointing to our shellcode, in a known
    location. Then by using SetWIndowLongPtr() API we replaced the pointer to
    the lookup table with the address of our new lookup table. The service
    would use our lookup table and execution would therefore reach the
    shellcode.

    Vendor Status:
    Microsoft has issued a security patch that will mitigate this
    vulnerability. It is available at
    <http://www.microsoft.com/technet/security/bulletin/ms04-032.mspx>
    http://www.microsoft.com/technet/security/bulletin/ms04-032.mspx.

    ADDITIONAL INFORMATION

    The information has been provided by
    <mailto:brett.moore@security-assessment.com> Brett Moore.
    The original article can be found at:
    <http://www.securiteam.com/windowsntfocus/6V00F0UBFU.html>
    http://www.securiteam.com/windowsntfocus/6V00F0UBFU.html

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

    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.

  • Next message: SecuriTeam: "[NT] Limited \secure\ buffer-overflow in some old Monolith games"

    Relevant Pages