Multiple WFTPD Denial of Service vulnerabilities

["axl rose" <rdxaxl () hotmail com>]

Name of Advisory: Multiple WFTPD Denial of Service vulnerabilities
Severity:         Low
Discoverer:       axl (rdxaxl () hotmail com)
Released:         Today
Vendor Notified:  Today

WFTPD who? what? when?
~~~~~~~~~~~~~~~~~~~~~~
Vendor quote: "WFTPD Server has been a leading FTP server for Windows since 
it was released in 1993.   Its stability and security have long been relied 
on by technology companies, educational institutions, government 
departments, individuals and others, to provide a secure FTP site."

Tested versions
~~~~~~~~~~~~~~~
- WFTPD Pro Server 3.21 Release 1 (trial) (latest version)

All tested versions are vulnerable. Other versions may also be vulnerable.

Overview
~~~~~~~~
A remote attacker can allocate arbitrary amounts of memory on the vulnerable 
system, and force the WFTPD server process to use 100% of the CPU. Another 
DoS vulnerability allows an attacker to send a special string to crash 
WFTPD.

Vulnerability details
~~~~~~~~~~~~~~~~~~~~~
The FTP command buffer is default 512 bytes (513 bytes with the terminating 
null byte). Whenever the buffer is too small for one FTP command line, WFTPD 
will increase the size of the buffer by 512 bytes. If a remote user sends 
any bytes other than 0Ah to the server, and never sends a 0Ah byte, the 
WFTPD server will allocate more and more memory. It will eventually fail 
when it has allocated MaxAvailProgMem/2 bytes (because it needs a new and an 
old buffer to copy the old buffer, of approximately the same size, to the 
new buffer.)

To allocate all memory on the system, a remote attacker can connect less 
than 31 (log2(MaxAvailProgMem <= 2GB)) clients to the FTP. The first 
connected client can allocate MaxAvailProgMem/2^1 bytes, the 2nd client can 
allocate MaxAvailProgMem/2^2 bytes, and so on. This however, takes a lot of 
time mostly because of the 100% CPU utilization. To speed this process up, 
the first byte sent to the server should be byte 00h. That way, WFTPD will 
only check for 0Ah bytes in a null string which is considerably faster than 
scanning a 200MB buffer for a 0Ah byte each time a packet is received.

A variant of the above vulnerability to cause 100% CPU utilization is to 
send it a large enough buffer with no 0Ah or 00h bytes, and then 
continuously send it small packets with no 0Ah/00h bytes. It will scan 
through the whole big buffer each time it receives data looking for a 0Ah 
byte, which takes a lot of time. To make it twice as slow only send bytes >= 
80h. This will make it scan the buffer twice each time it receives a packet.

Finally, (for WFTPD Pro Server 3.21) a remote attacker who has logged in as 
a user with XeroxDocutech option set to 1 ("Servers\ <ftpname>\ Users\ 
<username>\ XeroxDocutech" :DWORD :1) can overflow a string on the stack 
causing the cookie to be overwritten by a 00h byte which will then terminate 
WFTPD. The probability for it to succeed is 255/256 = 99.6%. To exploit 
this, the attacker must send a MKD or XMKD FTP command to the server, 
specifying an argument big enough so that the absolute path when 
concatenating the absolute path of current directory with the argument is 
exactly 260 characters. Example, if absolute path of current working dir is 
"C:\ffttpp1\" (11 chars), the attacker would have to send a MKD/XMKD 
argument of length 260-11 = 249 characters. The string used to get the 
absolute path of the new directory is 261 characters long (264 if you count 
the unused bytes). The vulnerable code is strcat(dst, ".djo"), which when 
strlen(dst) = 260, overflows the string and overwrites the first byte of the 
cookie with a 00h byte.

Exploit
~~~~~~~
This is so easy to code yourself that I'll let you do it...

_________________________________________________________________
Get fast, reliable access with MSN 9 Dial-up. Click here for Special Offer! 
http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html