Re: .ida vulnerability..

["Ryan Permeh" <ryan () eEye com>]

well, i suppose i will post a response here, since i was the one that wrote
the exploit handed to microsoft.

firsrt, the heap grows with suffiencintly large requests.  we are talking
about 20k+ requests.
you probably will get cutoff if you try to put 20k chars in the url, and
besides, they will probably be converted to garbage anyways(the whole wide
char conversion).

in the exploit that we gave microsoft, we used a specific header(eeye:
data\r\n) to pad our requests onto the heap.  It have since heard of some
more ways to do this that are more reliable, but have no working code
implementing them.

right now, we have gotten code to run on 2k, xp, and nt, all service packs.
the code we provided microsoft was tuned out of the box to consistantly hit
a 2k server/advanced server sp1 install, but it could have been tweaked(we
made padding and eip based on command line ops) to work on any of them.

The core reason we have not publicly released(and it seems that the media,
along with numerous other sources think we already have), is due to the high
skew factor in this.  an exploit that runs 90% of the time on sp1 will crash
nt 100% of the time.  and nt's heap is very sensitive to this, so you
basically have to be right no, and it tended to taske us about 3-4 times
with a debugger to get "right on".

This problem is real, and whether we do or donot decide to finally release
code, i know of multiple exploits that are in the wild(not public, but not
ours, nor based on any code we have produced), some with higher degree of
accuracy in differing situations.


In this vein, i beleive that it may be a wise thing for this group to
examine the following information:
http://www.msnbc.com/news/592066.asp?0dm=C1BQT

since it deffinately affects everyone who deals with vulnerability as
research.  eEye is a commercial organization, and we publish research as
part of our commitment to the security community, groups like this threaten
to make people and groups that publish vulnerabilty research into the bad
guys, rather than the companies who create vulnerabilities in their systems.
just something for everyone to think about.


Signed,
Ryan Permeh
eEye Digital Security Team
http://www.eEye.com/Retina -Network Security Scanner
http://www.eEye.com/Iris -Network Traffic Analyzer

----- Original Message -----
From: "Joakim Sandström" <jode () tribalstorm com>
To: "Vuln-Dev" <VULN-DEV () SECURITYFOCUS COM>
Sent: Monday, June 25, 2001 7:11 AM
Subject: .ida vulnerability..


> Hi Folks,
>
> I had some time off work last weekend so I took a look at the new .ida
> vulnerability. I was debugging
> a win2k adv server with sp2 installed. First of all I tried to get eip
over
> run and successfully did
> that after trying out different params. The first thing I noticed was that
> (as stated on eeye's pages) that
> the buffer get's converted to wide character (which makes this really
> tricky) .. But according to
> eeye's description about the vuln I should be able to push in more stuff
and
> make the heap (or whatever)grow larger so I could produce some of my own
> input data to appear in mem locations as 00430043.
> First of all I must admit I didn't succeed. Seems to me that the
exceptions
> from the overflow occur before the "payload" get's parsed into the memory.
I
> can't locate the payload anywhere.. (and in some occasions the actual
> buffer).
> > From what I know.. I see this as a deadlock situation.. Maybe it's
doable..
> Though I don't have time
> to further investigate the vuln. Has anyone else tried it out? Results?
Any
> certain combinations of payloads and overflow size which produces a good
> result? I bet this all varies allot form win2k version and sp versions?
> Another thing that wonders me.. Why haven't eeye released the proof of
> concept they are promising on their website? I'd really like to see
(follow
> the flow) how you can get all this together. The exploit eeye had sent to
> microsoft  was based on win2k prof.and sp1. Is this because it was
un-doable
> on win2k servers?
>
>
>
> thanks,
>       JODE