COMMAND
NetTerm FTP Daemon
SYSTEMS AFFECTED
NetFtpd distributed with NetTerm 4.2.a/4.2.2/4.2.1 and possibly previous versions
PROBLEM
Jeremy Iverson found following. Many insecure options are
enabled by default. A number of buffer overflows also exist.
Users of the program NetFtpd (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. *NONE OF THIS AFFECTS THE
NETTERM CLIENT, ONLY THE FTP SERVER BUNDLED WITH IT!*
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 tested 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.
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.
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
user1:encryptedpass
user2:encryptedpass
etc..
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. Also, the encryption method is weak and would not take
much skill to break.
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.
SOLUTION
InterSoft (sort of) responded. See
http://www.dragonmount.net/security/vra/InterSoft/NetFtpd_response.htm
for details.
Don't enable insecure options by default. Perform length
validation on all input to the program. Immediately cease use of
NetFtpd unless you are absolutely positive that it is configured
correctly, your box isn't open to a console attack, and the only
account activated is your own. Disable anonymous access
immediately.