NetFTPD DoS and Insecure Settings - 15 Nov 1999

NetFTPD Server Subject to Attack
Reported November 16, 1999 by
Erik Iverson
  • NetFtpd distributed with NetTerm 4.2.a/4.2.2/4.2.1, and possibly previous versions


According to the bulletin at Dragonmount, Many insecure options are enabled by default. A number of buffer overflows also exist.

Users of the program NetFtpd (which comes standard with the newest version of NetTerm 4.2.a, and possibly previous versions) are vulnerable to myriad security problems. The ones we have concentrated on deal strictly with the FTP server itself, and not the NetTerm terminal emulation program.


  1. By default, the FTP server allows access to the entire hard drive to anybody presenting any user name. There is an option that says "Accept calls from anyone." This option is misleading; I took it to mean "Accept connections from anyone.", not "Let anyone log in." Why would there be an option to let anyone presenting any userid full access to the hard drive? By default this is on, and all servers I have seen configured have left this option turned on. This should not be an option, period. If it is an option, it should not be the default. Absolutely ridiculous.

  2. Anonymous access is allowed by default. Sure, many FTP servers come configured this way. Unfortunately, the default (without any configuration) read and write drive for user anonymous is C:\. This means even if you force people to provide a login/password, allowing anonymous access without changing the directory privileges gives anyone full access to the hard drive. Also, write privileges do mean write; overwrite even. Running the FTP server "out of the box", anyone can upload a new autoexec.bat, etc. Plus, users have delete privileges by default. There isn"t an option to turn off deleting files, or even writing files for that matter. It is all or nothing with this program. The default read/write drive for anonymous should be a directory lower than the root directory. Perhaps C:\Program Files\NetTerm\FtpRoot would be more appropriate. Secondly, anonymous access should be turned off by default.

  3. The password scheme is weak. First and foremost, there is no "administrator" type password. Anyone with console access can add/delete/and change any user"s password. There should be an admin password required before any of this action can be taken. The passwords are stored in a file by default called "password". The form of the file is


    So, by having access to this file, users don"t need to use the program as front door. They can edit this file by hand, adding/deleting/changing users passwords. In most cases, users can upload a new "password" file, overwriting the current settings. This assumes the directory problems aren"t fixed as noted in \[2\]. Also, the encryption method is weak and would not take much skill to break.

  4. Surprise, a closed-source Windows FTP Server has a buffer overflow. Nothing exciting here. It appears that the USER command is truncated to 16 characters; no problem there. The PASS command also seems to stand up to our testing. However, there are problems with the following when a large string \[~1024 chars\] is sent to the server: dir, ls, mkdir, pass \[when used for anonymous access\], delete, and rmdir. These all crash the server with an invalid page fault. From the looks of it, remote code execution is a definite possibility. You"ll notice that PASS has an overflow only when user anonymous logs in \[i.e. where it asks for email address\]. This is why anonymous access should be disallowed immediately if you are to continue using this product.

Users should thoroughly test that anonymous access is disallowed, and that any user name will not work. When logging in, they should restrict themselves to certain directories, not the entire C:\. This way if their username/password is compromised, the entire C:\ will not be open. There may well be other exploits that work in this manner. If you allow anyone access, even anonymous, do not let them read the directory the program was installed in. They will be able to retrieve the password file remotely and steal all the encrypted passwords, which may yield elevated access.


InterSoft has been notified about this problem. Their response to Dragonmount was brief, sharp, and highly unprofessional. Kenneth R. Robinette of InterSoft replied, "You guys are a bunch of fools..."

You"d be well-advised to steer clear of companies that display such complacency.

Discovered by Erik Iverson

Posted here at on November 16, 1999
Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.