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" <jodeat_private> To: "Vuln-Dev" <VULN-DEVat_private> 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 > >
This archive was generated by hypermail 2b30 : Tue Jun 26 2001 - 23:24:38 PDT