> 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
This archive was generated by hypermail 2b30 : Sun Dec 23 2001 - 08:15:27 PST