Vulnerability Development mailing list archives

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


From: dullien () gmx de
Date: Sat, 22 Dec 2001 15:40:15 -0800

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,
dullien () gmx de


-- 
Mit freundlichen GrĂ¼ssen
dullien () gmx de                            mailto:dullien () gmx de


Current thread: