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

["|Zan" <izan () deepzone org>]

> 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]

No, step 3 can't be represented with that basic approach. "Execute buggy code"
is more complicated. Function setting up an exception frame going to call
another nested "calls" (giving us one or more "return addresses" to exploit). I
have viewed that IIS is a very modularizated code so when it sets up that
exception frame it choses that .dll or piece of code will handle that request
and then it call the proper/s function/s.

In a nutshell you have 420 bytes to smash *THE FIRST* return address. Exception
frame is quite far in stack in that moment.

Idea is play *all exploit* in 420 bytes. In that way you don't overwrite unknown
data and keep intact previously installed exception frames. Those frames are set
up by IIS. I don't build any frame and i don't try overwrite any frame in any
moment. IIS is our friend!

> 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 overflow local data until the first return address. If my "return address"
fails then IIS catch my fault on "its exception handler". Its exception handler
has been installed in "its process space" so while it executes its "exception
handler" OS can't kill/unload overflowed process and IIS wait my *confirmation
input* to exit.

In my *default win2k spanish server* exception handler previously installed show
me an error window asking to click if i am logged in. That is, that exception
handler is "interactive" (it show a error message if you are log in) and it can
be seen like a "thread-freezer" if *anybody* click that button.


> 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 ?

Yes, it is. If you works in that tiny buffer and keep clear the first exception
frame containing one valid address pointing to a valid exception handler you can
keep living the server when you fails overwritting the return address on closed
addresses.

> 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.

Exception handler is "installed by thread" in IIS and another commercial servers
that i have seen. When overflow happens it try to notify with a splash window
*before to kill* overflowed process (you only will see this window if you are
logged in. It shows an error asking about "Accept". It dies (OS unloads process)
**when you click button but while theirs fellow threads can be exploited**
because continue working).


> 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 ?

I point it on my code but if it fails the first exception handler takes control
working like a freezer. Notice that if you try long payload sizes you'll lose
control.

> 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 ?

They change but IIS pushs a valid exception frame pointing in a valid exception
handler with each OS. Idea is protect your code with a previously installed
exception frame.

> 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 :)

I was speaking about "splash-windows" because if you want to see or make
"cheap-debugging" you need log in. If you aren't logged then Windows isn't going
to show any window but we get same effect: "a freeze thread keeping another
theads ok".

Attached exploit is working with "Default mode" (brute forcing and more ...) in
"Windows 2000 Server - Spanish edition". If you try this exploit in a german or
french box it'll fail. I have added DeePo to get fingerprints in your box. You
can change your "attack mode" to "Custom mode" and import your fingerprint.
DeePo fingerprints aren't valid fingerprint to "Default mode" but all this
information is contained in golondrina paper.

regards,
|Zan