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

From: |Zan (izan@deepzone.org)
Date: 12/22/01 

From: "|Zan" <izan@deepzone.org>
To: <dullien@gmx.de>
Date: Sat, 22 Dec 2001 23:51:26 +0100

hi dullien,

> there are numerous points in your post which need commenting.
> First off, please do not be offended by anything I might post
> regarding your publication, I seriously like it and have to admit it
> is quite a bit better than your average post on these mailing lists :)

Thanks ... i think! XDDDDD

> Z> Brute-forcing. What Service Pack is installed ?
>
> The technique you describe here is not very well thought-out.
> First off, let's assume you're dealing with a system which is
> Windows(NT/2k/XP) and we do not know much more. NMAPing or XProbing is
> not possible due to correct filtering before our data actually hits
> the host.
>
> You have no way to fingerprint here. Of course, as dying
> processes/services are restarted under 2k/XP, you can try all possible
> offsets you have collected, but at worst you'll crash the service once
> for every failed guess (let's say you have a choice between
> NT4SP5/NT4SP6/W2kSp0/W2kSp1/W2kSp2/XP, that means in the worst case 5
> server crashes)
> times, each time generating lot's of Event Log entries. In the worst
> scenario, your attacked process doesn't die but hangs in a loop
> somewhere - which is certain to attract the sysadmins.
>
> Under NT you don't even have that luck - one missed shot and you're
> out.

No, no, no ... that isn't the correct way! Objective was get stability probing a
range of well known *minimal* fingerprints *with a closed vulnerability*.

For example, in proof of concept example i brute forced only two environments
Win2k sp0 and sp1. XP or NT aren't vulnerable with that closed vulnerability so
i don't need brute force them. Later i outline that NMAPing can be the best way
to get the correct service pack if you can reach the full tcp/ip stack but if
you can't do it "Application's brute-forcing" can be a alternative. Like you'll
see it is working fine but it is only that ... another method.

>
> You're claiming that exception handlers can be used to increase
> stability of exploits - by using them inside the injected code one can
> prevent segfaults due to nonpaged pages etc.
>

No, exception handlers are set up by buggy application. I am only abusing them.

If you can minimize your hit-size (golondrina objective) then you can abuse
previously installed exception handlers (this is a consecuence).

For example, WWW server fly out pages in this way ...

1 -. initialize data
2 -. set up an exception handler
3 -. execute buggy code (overflow) protected by exception handler
4 -. release exception handler

Like you can see overflow happens in step 3. We take a "exception handler"
waiting us!

In IIS, for example, it show us a "memory error" and freeze a thread *BUT* n-1
threads are working fine yet. We have hitted/tested and server continues
working.

> While this is partially not a bad idea, it completely misses the
> point.
> Using SEH in hostile code is an old and boring technique. To be quite
> frank, most people didn't realize SEH existed before Win32.Cabanas by
> Jacky Qwerty/29A.
> But the main problem, not knowing which addresses to use to return to,
> can not be easily solved that way.

Like i said code isn't inoculated; it is previously installed by server. Return
address is on a valid and trusted handler installed by server. If that trusted
and valid handler is interactive (it shows a splash-windows like in IIS) then it
will freeze that thread (waiting our input) giving us another (n-1)
opportunities.

If it was a "death window" telling us something like ".... IIS will be
restarted. Press OK to continue ..." then it can be exploited too if code
showing that death-message lives in remote server. It is possible because all
their friends threads can continue living like in IIS.

>
> All in all the paper is a nice review of tricks one can play in
> multi-threaded environments -- not necessarily only under NT but under
> any OS providing kernel-supported threads. But I'd recommend removing
> the 'revolutionary new technology'-style from the document :)

We are spreading this document in non very cool sites where this style is a
important imposition. I can't generate 50 different styles with each post so i
chose one-style leting me a cross-post. In any way, i haven't seen the phrase
'revolutionary new technology' ... perhaps you appreciate that style where i
wanted show possibilities and impact :)

> The
> document is good & technical enough not to require the stupid bragging
> the security industry is so full of these days.
>

Thanks for your time!

|Zan

Relevant Pages