Vuln Dev
Win-based FTP server stack overflow, /GS, safeSEH? Nov 19 2006 02:41AM
drunken_chin yahoo com

Despite their decreasing presence, and my critical lack of experience, I am trying to learn more about typical C and C++ memory corruption techniques and have found an apparent pre-auth stack overflow in an obscure FTP server. The app appears to be compiled with a recent version of Visual Studio, evidently using /GS and perhaps SafeSEH as well. I had no joy doing anything other than a DoS with XPSP2 and have moved backwards to a Win2K system, but am still having trouble getting anything other than a DoS. Anyone who has time/interest in helping with this, I'd appreciate it. Details:

Buffer of 17500 A's generates the "Buffer overflow detected!" message. Since the app/windows handles the exception, setting Olly to intercept doesn't work, so I've attached to the process after the overflow takes place.

I've apparently found my buffer in the stack of the main thread:

00127000 00009000 00030000 stack of main thread Priv RW Guarded RW

0012FC2C 008F6E01 ASCII "AAAAAAAAAAAAAA".... (repeats)

The section of memory where this stack is located is marked "RW Guarded", so I assume this stack is non executable, by nature of the compiler options, not the OS - is that correct? I didn't think Win2K had the option to use a nonexec stack within the OS.

No matter where I seem to go as I fumble about with Olly, I am not finding where my buffer is overwriting any of the registers (looking for EIP of course, but something leading towards EIP would be nice). If it's not landing on a register, what else might it be hitting? (more research required)

It was suggested to me to lengthen the fuzzer buffer and look for an SEH pointer overwrite, but from what I can tell, that's not happening either. I probably just don't really know where to look, but every SEH value that I inspected no matter how large I increased the buffer did not contain any portion of my A chars. Could this be due to safeSEH compilation options? My limited reading makes me think that if this is compiled with /GS, and with SafeSEH, I might as well give up this approach and simply report to the vendor as a DoS.

I've done a small bit of tracing to watch how things flow into NTDLL, and USER32 as this takes place, and have done some backtracing but I'm obviously missing something (not a big suprise).

How can I tell from the binary if it was compiled with SafeSEH? Someone mentioned to me how you can detect /GS (which I've forgotten), but I don't know about SafeSEH.

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus