Re[2]: [DeepZone Research] It's time to disclose GOLONDRINA Anarchy (draft + exploit included!)

From: dullienat_private
Date: Sat Dec 22 2001 - 15:40:15 PST

  • Next message: Paulo Ribeiro: "WebSitePro format bug + (old) its path."

    Hey |Zan,
    
    Z> No, exception handlers are set up by buggy application. I am only abusing them.
    Z> If you can minimize your hit-size (golondrina objective) then you can abuse
    Z> previously installed exception handlers (this is a consecuence).
    Z> For example, WWW server fly out pages in this way ...
    Z> 1 -. initialize data
    Z> 2 -. set up an exception handler
    Z> 3 -. execute buggy code (overflow) protected by exception handler
    Z> 4 -. release exception handler
    Z> Like you can see overflow happens in step 3. We take a "exception handler"
    Z> waiting us!
    Z> In IIS, for example, it show us a "memory error" and freeze a thread *BUT* n-1
    Z> threads are working fine yet. We have hitted/tested and server continues
    Z> working.
    
    Well, after step two your stack looks like this (left are lower
    addresses)
    
    [local data][exception structure (8 byte)][frame ptr][return address]
    
    So you overflow local data, and kill the exception structure with some
    data you've provided. Do you make the exception handler point to code
    you've submitted or execute code that's already there in the program ?
    
    I see your point - if you make the exception handler execute some code
    which will prevent the service from actually dying - or am I wrong ?
    
    If the exception handler doesn't terminate the service & restarts it
    immediately, it is broken by design - a segfault should never
    attempted to be recovered from as everything (heap structures of other
    threads etc) could have been corrupted.
    
    Z> Like i said code isn't inoculated; it is previously installed by server. Return
    Z> address is on a valid and trusted handler installed by server. If that trusted
    Z> and valid handler is interactive (it shows a splash-windows like in IIS) then it
    Z> will freeze that thread (waiting our input) giving us another (n-1)
    Z> opportunities.
    
    I have to admit I do not fully understand what you're doing.
    The return address is something you supply - where do you point it ?
    And if you point it to some code that is already present in the
    process address space, how do you know it doesn't change through
    service pack variations etc ?
    Normally, services do not interact with the user desktop, why would
    they show a splash-window ? My IIS (win2k default install) just dies &
    restarts, no window is being shown :)
    
    
    Cheers,
    dullienat_private
    
    
    -- 
    Mit freundlichen Grüssen
    dullienat_private                            mailto:dullienat_private
    



    This archive was generated by hypermail 2b30 : Sun Dec 23 2001 - 08:08:01 PST