<Snip> >On the server side we have an "Application Error" message for >inetinfo.exe. "The instruction at '0x710f8aa2' referenced memory at >'0x41414156'. The memory could not be 'read'." > >If we take a look at our registers we will see the following: > >EAX = 0000005C EBX = 00000001 >ECX = 00D3F978 EDX = 002582DD >ESI = 00D3F978 EDI = 00000000 >EIP = 710F8AA2 ESP = 00D3F644 >EBP = 00D3F9F0 EFL = 00000206 > >There is no 41 hex (Our overflow character) in any of our registers so >we chalk this up as a DoS attack for now. <Snip> >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. >Lets look at our registers once again: > >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. >:-] > >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. In both cases EIP and EBP are left unmolested. While you may be able to do something by manipulating the other registers I highly doubt this case is exploitable. 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. For a good example of this situation try the following experiment using 'pico' the lovable text editor. On a linux box try: pico `perl -e 'print "a"x4000'` any version will do. You will be greeted with a segfault, on close inspection you will see the same situation here, corruption, but not enough corruption. Now, try out the same experiment on the same version of pico on an OpenBSD box. And you will be greeted with the rush of seeing execution jump to 0x41414141. Curious, eh? The more secure of the two operating systems is easily exploitable, yet the other is not. I did not look too closely at this, but its evident that the same code can be exploitable when built under different conditions. I suspect the same will be true of IIS, so you may get control of the processor with a specific revison but not another. Seth M. McGann / smmat_private "Security is making it http://www.wpi.edu/~smm to the bathroom in time." KeyID: 2048/1024/E2501C80 Fingerprint 3344 DFA2 8E4A 977B 63A7 19E3 6AF7 4AE7 E250 1C80
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:30:23 PDT