> >On the server we have the same "Application Error" message for > >inetinfo.exe except this time "The instruction at '0x722c9262' > >referenced memory at "0x41414141'." This is looking mighty interesting. That's because it overwrote a pointer (a bss overflow). > >EAX = 00000000 EBX = 41414141 > >ECX = 41414141 EDX = 722C1CAC > >ESI = 41414141 EDI = 41414141 > >EIP = 722C9262 ESP = 00D3F524 > >EBP = 00D3F63C EFL = 00000246 > > > >There sure are a lot of 41 hex codes in our registers now. >:-] > > This is because it's overwriting data in the bss (where static poitners are stored), which is then being used as arguments in something like strcpy() or memcpy(). That fails because the pointer points to an invalid address. The reason I assume it's a static pointer is because it's not overwriting EIP. If it were on the stack overwriting the local pointer, it'd also be able to overwrite EIP. That's because local variables come below the return addresses on the stack and also have the capability to overflow the return address (unless the program restricts it). > >So to wrap it all up what we have here is a DoS attack against any IIS > >server with ftp access. Keep in mind we have to be able to login. > >However, Anonymous access is granted on most servers. Once we have > >overflowed IIS all IIS services will fail. (I.E. The web service, NNTP, > >SMTP etc..) What we have seems to be a very interesting buffer overflow. > > Well, unless I missed something neither of these cases indicates an easily > exploitable buffer overflow. Well, I think you both did. First, just because something doesn't overwrite EIP, doesn't mean it can't be exploited! Second, it proably _is_ an easily exploitable buffer overflow. You probably meant to say it's not an easily exploitable "stack-based overflow." That's correct, because it is not a stack-based overflow. See below. > In both cases EIP and EBP are left unmolested. EIP and EBP are left unmolested because it's not a stack overflow; it's a bss overflow (specifically, it's overflowing a static buffer in the bss). If it were a stack overflow, the arrangement of the variables wouldn't have mattered (AFAIK). See my comments above. I explained how I can tell (well, why I assume) it's a static buffer overflow in the bss. Also, this can most likely be exploited fairly easy (as opposed to Seth's comments). I cover several exploitation methods in an article I'm going to post following this (look for "w00w00 on Heap Overflows"). Given that you were able to overwrite the pointer with an arbitrary value, you can also guess offsets into another buffer, that allows indirect exploitation (filename pointers are a great example of this). For example, with filename pointers, you could change the pointer from a valid string to your argv[1], which could contain "/etc/shadow". > If for some reason the order of variables on the stack is changed > (perhaps with a different compiler or optimization) you may very well > get the extra reach you need. As it stands you dont have it here. I'll bet this has nothing to do with stack overflows. > I suspect the same will be true of IIS, so you may get control of the > processor with a specific revison but not another. I doubt this is true. I'm not sure why most people assume it's always a stack overflow. In this situation, I think it's much more likely this is a heap/bss overflow. Anyway, after I send this off, I will send out an article w00w00 Security Development (WSD) and I have been working on for the last few weeks. Although it has a few more things that should be cleared up, and a few Look for the article, "w00w00 on Heap Overflows", today or tomorrow (it will be posted here and to comp.security.*). more case studies to add, this was an appropriate time to send it out. I will post a final draft/revision after I finish adding everything. Look for the article, "w00w00 on Heap Overflows", today or tomorrow (it will be posted here and to comp.security.*). I apologize for any errors in this post. *************************************************************************** Matt Conover <mattcat_private> RSI R&D Team ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RepSec, Inc. (RSI) [http://www.repsec.com] w00w00 Security Development (WSD) [http://www.w00w00.org] 'finger mattcat_private' for pgp key and information ***************************************************************************
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:31:05 PDT