MS IE FTP Folder Shell Extension Buffer Overflow

[s.hird () STUDENT QUT EDU AU (s.hird () STUDENT QUT EDU AU)]

I recently discovered an error in the way the FTP Folder 
shell extension for IE5 handles long folder names. Although 
the full impact is yet unknown, its quite possible there 
could be a similar security risk to the past 'res://' 
issue. To evalute the full risk of the bug, and potential 
to exploit, further investigation is required, and I 
unfortuantly don't have the time or patience to 
debug/dissassemble/trace etc the code, so I am making it 
publicly available for those that do.

The bug/exploit essentially involves passing a long 
directory name to CWD to the FTP Folder extension when 
connected to an existing site. In tests this was possible 
either by simply including it in a HREF, ie, a 
href="ftp://ftp.microsoft.com/%90%90longstring"; /a. It was 
also proved possible to trigger the fault by having long 
directory names on the server itself, and following the 
directories until the buffer overflowed. Actually this is 
how the bug was discovered, by browsing an FTP site where 
someone had attempted to exploit the recent WsFTP bug with 
long directory names. (site not included here) An 
interesting point with triggering the fault this way is 
that the stack dump contains part of the URL in Wide Char 
format, although as stated, it hasn't been fully 
investigated and whether or not this is significant is 
unknown.

As 'FtpWebView' is 'safely scriptable' it may also be 
possible to exploit the bug through ActiveX or other means 
as well, although this hasn't been looked into. I have 
managed to trigger the fault at various addresses.

In SHELL32.DLL v 4.72.3110.6

@7FCE2373

In MSIEFTP.DLL v 5.00.2014.209

@71211EE9
@71215C92
@712121D8
@71215BE6

This last address is interesting, it appears to be code 
which is called when an invalid/not existing directory is 
attempted to CWD to, at this address is the following code;

mov   edx, [eax]
lea   [ebp][0FFFFFA4C]
push  edi
push  ecx
push  eax
call  [edx + C] <-- possible call to code.

and eax seems to be loaded with a seemingly random value 
when the fault occurs. If EAX is somehow controlled, or 
happens to be our magic value, I assume running arbitary 
code is quite possible, as the url is decoded and stored in 
binary format in memory, although I am unsure as CS <> SS, 
and I'm not sure exactly where in memory it is stored. So, 
buffer overflow experts are welcome to investigate this 
further, and please, feel free to send me any comments or 
findings.

Shane.