Support - Bug Pages

This section is for those issues that are not crashes, and do not display a particular error message, but are nonetheless disconcerting behaviors to some users.

	2004/02/29 SSL / TLS truncation - On Windows 2000, WFTPD Pro would often truncate files to 8192 bytes when using SSL and TLS to transfer files.  This has been fixed in 3.21 R2.
	2004/02/29 SSL / TLS truncation 2 - When using certain encryption algorithms in SSL / TLS (particularly those negotiated when "FIPS compliance" is turned on in the Security Policies), connections from OpenSSL-based clients would be terminated soon after negotiating SSL / TLS encryption.  This has been fixed in 3.21 R2.
	2004/02/29 Overlong commands - An attacker could use up available memory, and essentially perform a denial of service attack, by sending an unterminated command sequence.  This has been addressed by adding the server-specific setting, "MaxCmdLine", which represents the number of bytes we will accept in the longest command line.  Command lines that go over this number will cause disconnection of the client that sends them.  The default for the MaxCmdLine setting is 2048, and can be set in the INI file or registry - there is no user interface for this feature, as we do not expect users will need to change it.  This has been fixed in 3.21 R2.
	DSS Certificate Support - When Microsoft's Certificate Import Wizard imports a DSS / DH certificate, it places it into a Cryptographic Service Provider (CSP) that is incompatible with SSL and TLS.  The Control Panel will now detect this when you select the certificate, and will offer to move the certificate into the correct CSP for you.
	Unable to delete users - In "Classic WFTPD" Security Model, WFTPD Pro 3.20 Release 1 failed to completely delete users when asked.  Users' entries were deleted, so that they could not log in, but the names were not cleared from the user list or the registry.  This has now been fixed.
	Infinite loop with 100+ users - in "Windows" Security Model, WFTPD Pro 3.20 Release 1 would go into an infinite loop, with the hourglass displayed, if there were more than 100 users.  This has now been fixed.
	SSL / TLS Interoperability Issues - The SSL / TLS code in WFTPD Pro would occasionally cause the generation of encrypted traffic that was rejected by some clients.  The encryption code now defaults to an 8k maximum message size.
	5/24/2001 - Directory traversal vulnerability - Windows 95, 98, ME. As noted in the "What's New" section of our most recent version, 3.00 R5, there is indeed an effect on WFTPD's behaviour caused by the new path name expansion code.  On Windows 95, 98, and ME, the string "..." is understood by the operating system to mean "up two directories" - this is not currently expanded out in our code, and is hence passed into the operating system, leading to the ability of a user to venture outside of his/her restrictions, and possibly to touch files not in accordance with defined rights.  Again, as noted in the "What's New" section of our help file, this can be disabled by adding the entry "GFPNMethod=0" to your WFTPD.INI file, in the "[Server]" section.  If you do not have a "[Server]" section, then it can be created anywhere in the file.  Do not create two sections labeled "[Server]", as only the first will be accessed. Thanks go to joetesta for reporting this problem to me.  Byterage also reported this problem to the bugtraq mailing list, but did not contact me first, which I consider to be impolite at best.  Because there is a valid workaround with no functional change, we will not be releasing a new version of the software to cover this vulnerability.  WFTPD and WFTPD Pro are not vulnerable on Windows NT, 2000 or XP, either with or without the GFPNMethod setting.
	Slash-dot-dot DoS - unrelated to the "Giving Thanks" issue below, a user could use the sequence "LIST */../*/../*/.." [or more levels] to cause the server to use up processor time and resources at an alarming rate.  We now refuse to process any listing command (LIST, NLST and STAT) that includes the string "/.." (slash, dot, dot).  This Denial-of-Service (DoS) attack has been reported on several FTP servers recently, and has been fixed in version 3.00 R4 of both WFTPD and WFTPD Pro.
	Memory leaks - a failed "rename" command caused 256 bytes of leak each time it was used.  Fixed in version 3.00 R4.
	mget failure - A problem in the NLST code was preventing 'mget *' and related commands from working correctly.  Fixed in version 3.00 R4.
	Giving Thanks - - with the usual spectacularly bad timing, a user reported a security flaw to us hours after we released a new version, and minutes before our main developer was due to leave for an extended Thanksgiving holiday weekend.  He was persuaded to stay long enough to patch a fix together, which has been tested since then and is ready to download.  The detail?  Well, it seems that the sequence "/.." was not correctly checked for, and users could get around their restrictions.  This has been fixed in WFTPD 2.41 RC15 and WFTPD Pro 3.00 R2.  Note - in fixing this, we introduced a problem whereby some restricted users could not access files or do directory listings.  This has been corrected in WFTPD 2.41 RC16 and WFTPD Pro 3.00 R3
	NTFS streams - does anyone really know what they are?  Suffice it to say that a .LNK file stored on an NTFS volume could be downloaded with a little chicanery, by accessing its main data stream specifically.  This flaw has now been fixed in WFTPD 2.41 RC15 and WFTPD Pro 3.00 R1.  Visit our "downloads" page for a tool to allow you to list extraneous streams.
	Files on UNC shares inaccessible - due to an unexpected behavior of the API call GetFileSecurity, we reported some files and directories as inaccessible, when they were more accurately described as unsecured. Fix: 2.41 RC10 and above has fixed this issue, by assuming that all files we cannot get security information on are available for access.  [This doesn't cause security problems, since we still have to ask the OS / NOS for the file, and it will refuse if we don't really have access]
	Directory listings stop - under some rare conditions, it's possible that a directory listing will not produce the terminating "226" response - this will have the effect of stopping the FTP client in its tracks while it waits for a response that will never come.  Usually, this is caused by the behavior of Unix FTP clients. Fix: 2.41 RC10 and above has fixed this problem.
	WFTPD Pro can't access drive mappings - nor can (or more properly, nor should) any other services.  Services run in a different 'context' than any user that is logged in to an NT system locally. Often, they are not running as that user, and in that case especially, it would be a gross violation of security for the service to have any access to those drive mappings. However, even when the user is the same as the user that the service is set to run as, they are treated as two separate logins, with their own access to various drive mappings. Further reading: Microsoft's Knowledge Base, particularly articles Q115848 (removed), detailing reasons why a service should not create a drive mapping, Q121073, which mentions why the Schedule service can't access drive mappings, and Q130668, which shows problems caused by creating drive mappings in the Schedule service. A less involved explanation - imagine you have an NT system, used by Eric and Fred. They each map drive X when they log in, Eric to the accounting and payroll server, and Fred to the games directory. Fred logs in, and directs a user to access the X drive over FTP to download a game. Eric comes by, sees the machine unattended, apparently doing nothing, logs Fred out, and logs himself in. The user that connects to WFTPD Pro, if he could access the X map, would now find himself with full access to your company's accounts and payroll. Fix: WFTPD and WFTPD Pro version 2.40 and above support the use of UNCs as directory names, so Fred can direct his user to enter the command "CD //FREDSSYSTEM/GAME_SHARE" to visit his games.

DUN disconnection - If WFTPD or WFTPD Pro is listening at a specific IP address, that is granted through a dial-up connection using Microsoft's Dial-Up Networking (the new term for RAS), and the connection dies, then WFTPD is not informed of this, and can no longer accept incoming connections - even when the link is re-established with the same IP address. Technical: Use of "NETSTAT -AN" will still show the socket is marked as "LISTENING", but an attempt to ftp to that address will result in "connection refused". (While the connection is down, you will get "No route to host")  There is no way currently available to check that the listening socket is unreachable from within WFTPD. Workaround: When WFTPD runs with no arguments, it listens for all incoming connections on the FTP port (usually 21). WFTPD Pro can be configured to do the same by creating your virtual host with an IP address of "0.0.0.0", and a port of "ftp" or "21". Such a generic listening socket will survive disconnection and reconnection. Alternate Workaround: When you hear reports from your users that the server is inaccessible, restart the listening socket. On WFTPD, you do this by simply closing and then restarting the program. On WFTPD Pro, you must either stop and restart the affected virtual hosts in the WFTPD Pro Control Panel applet, or stop and restart the service as a whole. Note that the disconnection doesn't affect connections other than through DUN, so it may not be a wonderful thing to do to stop the whole service if someone is accessing your server by a local Ethernet. Status: Microsoft say this isn't a bug, and have not taken the opportunity to discuss it any further.