Re: Re[2]: ms03-043 questions

From: Dave Korn (davek_throwaway_at_hotmail.com)
Date: 11/12/03

  • Next message: Dave Korn: "Re: lame ms-ftp large file creation bug" 
    To: vuln-dev@securityfocus.com
Date: Wed, 12 Nov 2003 11:28:15 +0000

    ----- Original Message -----
    From: "einstein, dhtm" <einstein_dhtm@front.ru>
    To: <vuln-dev@securityfocus.com>
    Sent: Thursday, November 06, 2003 6:03 AM
    Subject: Re[2]: ms03-043 questions

    >Здравствуйте, A***.
    >
    >Вы писали 3 ноября 2003 г., 12:29:19:

    [SNIP]

    >A> my exploit for MS03-043 takes advantage of global SEH. I overwrote it
    >A> with a pointer to my shellcode. make sure ur message body size is
    >A> somewhere around 3656. works fine for win2k and winxp. btw u need to
    >A> send packet 2 times on win2k, on winxp access violation exception is
    triggered
    >A> only with 1 packet send.

      Have you made sure the MAC address of the destination host was in the
    sending machine's ARP cache before you send? If you attempt to send any
    kind of IP datagram to a host on your lan, and the arp cache doesn't have
    the relevant MAC address (either the dest host's MAC, if local, or the
    default gateway's MAC, if remote), then the TCP/IP stack will replace the
    packet with an ARP request. In the case of TCP you don't usually notice
    this except as a slight delay, because the tcp retries sending the initial
    SYN packet several times, but if you're attempting to send a single UDP
    datagram, it might be dropped and replaced with an ARP request, and UDP
    doesn't retry automatically. My exploit works fine on 2k with just a single
    packet, but you have to ensure the arp cache is valid, perhaps by pinging or
    sending any other kind of network comms to the dest machine first. I would
    suspect that when you were testing, the XP hosts's MAC was in your ARP cache
    and the 2k host's MAC wasn't.

      Also, it's important to ensure the system has been up and running in its
    logged-in state for at least a little while before you test it. There are
    lots of other services running in the same process space, and during the
    first minute or two after login, lots of processing and heap manipulation is
    going on within services.exe/svchost.exe (2k/xp). Leave the machine to get
    into a steady state before you test, however, and you should find your
    results pretty much 100% reliable. This has been my experience, anyway:
    send the packet early on, you tend to just crash some other thread in the
    service host before the messenger thread gets overflowed and owned; wait
    until it settles down, no problem.

    >A> my exploit executes successfully but its not
    >A> 100% reliable. try experimenting with message size. u might get
    >A> different results
    >
    >Do you mean the "final" exception handler (which is usually set by
    >SetUnhandledExceptionFilter) or per-thread handler at fs:[0] ?
    >This article: http://www.jorgon.freeserve.co.uk/ExceptFrame.htm
    >explains SEH in detail but the main difference of Heap based overflows
    >is that it's usually not easy to locate you shellcode in memory (like
    >in stack-based overflows). How do you overcome this difficulty ?

      When the UnhandledExceptionFilter finally jumps through the pointer in
    KERNEL32!BasepCurrentTopLevelFilter, take a look at the memory around the
    area pointed to by esi/edi/ebp, and somewhere you'll find a pointer to your
    shellcode (varies according to windows version and sp). For instance, under
    W2k SP2 you'll see that both [esi + 0x48] and [ebp + 0x70] point to the area
    just before your overwritten malloc chunk header. Then you simply need to
    find a jmp [esi+048h] instruction somewhere in the memory space of the
    service host process, and use that address to overwrite the UEF. Read Dave
    Aitel's recent paper about the DCOM bug, "MSRPC Heap Overflow - Part II",
    for a similar example.

          DaveK

    _________________________________________________________________
    Tired of 56k? Get a FREE BT Broadband connection
    http://www.msn.co.uk/specials/btbroadband

  • Next message: Dave Korn: "Re: lame ms-ftp large file creation bug"
    • Quantcast