Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Subject: XATO Advisory: Win32 Command-Line Mailers
Date: Tue Dec 12 2000 - 19:16:27 CST


                        Xato Network Security, Inc.

                      Security Advisory XATO-122000-01
                             December 12, 2000


              SMTP Command-Line Mailers on Win32 Web Servers


Systems Affected
Multiple vendor command-line mailers running on Win32-based web servers
(see below).

The majority of the command-line SMTP mailers available for Win32-based
systems are vulnerable when used to send mail from a web server. The
vulnerabilities found include the ability to:
- Read and/or write to the server's file system;
- Retrieve files from the server's file system as mail attachments;
- Bounce and/or spoof e-mail messages;
- Spam, flood, mail bomb, or otherwise use a server's resources without
- Bounce off a server to perform port scans;
- Bounce off a server to perform brute-force attacks to POP and/or SMTP
- Change default mailer options to route all e-mails through an untrusted
  mail server;
- Discover information about the server and/or company, including
  physical paths, e-mail addresses, and environment variables;
- Perform a number of DoS attacks on a server as well as using the server
  to perform DoS attacks towards other systems;
- View logs of e-mail messages and mailer configuration files.

The vulnerabilities found range from very minor to very serious and
immediate attention should be given if using a command-line SMTP

Although these vulnerabilities are obvious to many and similar holes
have been found in mailers on other platforms, we at Xato felt that it
was an issue that needed to be addressed because of the widespread usage
of these tools. In our research we found that many web servers are using
these command-line mailers. They are even included in several e-commerce
applications and many web hosting companies recommend their use.
Furthermore, some of these web-hosting companies go so far as to create
documentation explaining how to set up the mailers in such a manner
that makes them even more vulnerable.

We started this research on one mailer and were about to release an
advisory when we thought that perhaps we should look into some of the
other mailers out their. To our dismay, we found that the majority of
them had one or more vulnerabilities. As the number of mailers on our
list grew, we faced the dilemma of how to approach this. We did not
want to release twenty different advisories nor did we want to make one
large advisory that included all our research. We also did not want to
have to wait for and coordinate twenty companies to get around to
releasing patches before we released an official advisory.

Therefore we decided that our best approach would be to address the
issue in a general manner and leave it up to the individual vendors to
take the responsibility of fixing their own products. We hope that this
advisory serves as a lesson for both developers and web admins about
using DOS applications on web servers.

As we mentioned before, this is a vulnerability that may seem obvious
and some of the individual problems in specific mailers have been
addressed but we thought this should officially be documented because
people sometimes do not fix things unless they are told specifically
what to fix. We hope that this information will be integrated into
vulnerability scanners as well as intrusion detection systems so that
administrators are better educated in these and similar security risks.
 We expect to follow up this advisory with additional details about
specific vulnerabilities. We will not go into many exploit details
with particular command-line mailers now because there are so many exploits
for so many of the mailers. We are keeping this advisory general to
emphasize the nature of the problem rather than the specific

A command-line mailer can be an extremely useful and time-saving
administrative tool. However, although many of them were
designed to be used with a web server, most of them do not follow safe
practices making them a great security risk. The basic problem lies in
the fact that they are usually just plain old DOS applications. You can
stick just about any non-interactive DOS application into an executable
directory on a web server and run it remotely. The problem is that most
DOS applications do not realize or even care that they are being run
from a web server and so therefore they behave exactly as if they were
run locally from a command prompt.

For example, if you had a mailer named mailer.exe and you placed that
file in your cgi-bin directory on your web site, any visitor to your
site would be able to run that application by entering the url:


Now suppose that by executing "mailer.exe -h" from a command prompt the
user could view a list of options. The same thing can be executed from
the web by entering the url:


The resulting text sent to the browser would be the same list of options
that can be seen from the command prompt. To the mailer, there is no
difference in being run from a command prompt as being run from a web

Many web sites have some sort of feedback, technical support, or order
form that allows users to enter data which is then compiled into an e-mail
and sent to the right person at that site. It is a convenience for the
visitor as well as the web site operator. It is very common to simply use
one of the many freely available command-line mailers to accomplish this
Many of the mailers have CGI interfaces and some are solely designed
for web use. Most of them depend on the data sent from the form or
supplied through a server-side script. But most of the time the mailer
executable is located right in the web in a directory with execute
permissions. Anyone can simply bypass the web form and run the mailer
directly with the desired command-line arguments.

Now suppose that an attacker runs the command-line mailer with the help
switch and discovers that there are options to specify who the mail is
from (-f), who it is to (-t), and attachment (-a). So in our example,
one could send an e-mail from the command line using the following command:

mailer.exe -f joeexample.com -t meexample.com -a c:\logs\web.log

This same command can be run from the server by using the following


This command will mail you the file named web.log. Most command-line mailers
allow you to specify a recipient and a file attachment, allowing anyone
on the internet to grab any file that the web server has access to.

Looking at the options available for all the command-line mailers, we
found a number of great features that also introduced a number of
security holes. For example, one mailer allows the message to be sent to
a file instead of a mail recipient. This is a very dangerous feature as
it would allow one to create a batch file in the same directory as the
mailer executable. Since this directory is marked executable, the batch
file can be run from the web browser as well. Many of the mailers
required that the web directory be marked executable, readable, and
writeable. All of these things together make a very bad mixture. Another
problem with sending to a file is the ability to send data to other DOS
devices such as printers, modems, COM ports, etc.

Most of the mailers also allow one to specify the recipient as well as
the sender, allowing any one to use the server for spam, flooding, mail
bombing, resource draining, mail spoofing, denial of service, etc.

Other problems include INI and log files in the same directory as the
mailer, command-line options that override the default settings, the
ability to modify hidden form variables to exploit the mailer, debug
modes that reveal server information, and the ability to queue (and
unqueue) messages. One interesting attack we noticed with several mailers
is that one can set the server defaults from the command-line interface.
By routing all mail through an external SMTP mailer with full logging
turned on, one could easily spy on all mail sent through the utility. Such
an attack could easily go for a very long time unnoticed.

In short, we did not find a single command-line mailer that was secure
enough for us to recommend using on a web server. Many have made feeble
attempts to secure their products, but are not complete and have overlooked
many of the less serious yet still important vulnerabilities. To make
things worse, many users configure or use the mailers in such a way to
amplify the effects of the vulnerabilities. Some of these utilities
were never even designed for web use and therefore many of these security
issues were never even considered. On the other hand, some developers
have added some very good security features but they are either not
enough or they are not turned on by default. And finally, many web
sites operators are using older versions of utilities that do not contain
more recent security fixes.

We tested the following mailers and found all of them vulnerable to one
or more holes:

Title Web Site
BatMail v1.8d http://www.on3.com/tools/nt/mailexe/
Blat v1.85h http://pages.infinit.net/che/blat/blat.html
CGIMail v2.5 http://www.nsiweb.com/cgisoftware/cgimail
CLEMAIL v1.3 http://sureshot.virtualave.net/clemail
Comments v1.7 http://www.greyware.com
FormVar v1.61 http://www.cgimachine.de
GBMail v2.02 http://gboban.hypermart.net
MailForm v1.96 http://www.lss.com.au
MailMe! v1.6 http://www.arclab.com
MailPost v5.1 http://www.mcenter.com/mailpost
MailSend v7.15 http://www.radiks.net/jimbo/share.html
MailSend v3.18 http://www.dataenter.co.at
NetFormDD v2.9 http://www.seedlingsoft.com
Postie v6 http://www.infradig.com
SendFile v1.0 http://www.tntsoftware.com
Stalkerlab's Mailers V1.2 http://www.stalkerlab.ch/SMailers
WindMail v3.05 http://www.geocel.com
WebMailer Pro v1.2 http://www.geocel.com
WebMailer Lite v1.2 http://www.geocel.com
wSendmail v1.5 http://www.jgaa.com/

Please note that this list is by no means complete and it only represents
those that we actually tested. Not being on this list does not mean
that a mailer is safe. Also note that we have only evaluated executable
programs and have not even explored the many scripts and com objects
available. Most of these vendors have not been contacted other than
receiving this advisory. We strongly felt that because of the scope of
the problem and the number of vendors affected that it would be better
to distribute the advisory immediately.

User Solution
The problem with these utilities is that there is no really good solution
for fixing many of them unless the developers make some major changes
to how they work. The best interim solution may be to call the mailers
from a script and keep the actual executable out of the web root. This
will not work for all the programs or for all situations. Keep in mind
that some of these mailers have only minor problems while others have
some very serious holes. We will not be addressing all the specific
holes nor will we answer e-mails about specific problems. The best
solution is to look at how the mailer handles command-line options and
other user input and work with the developer to establish a good strategy
for using the mailer on your web site. You should also carefully read the
mailer's help file and any supporting documentation. Resources such as
BugTraq (www.securityfocus.com) can also provide insight into specific
security problems with your particular mailer.

Another solution is to use a COM-based dll for sending e-mails. Generally
they are more secure much of the burden of keeping them secure is on the
web developer. A very weak but possible interim solution until you can
fix things is to rename the mailer executable and change the standard

Developer Solutions
This is a good opportunity for software developers to look at their own
tools and the security holes they may contain. The biggest problem with
most of these mailers is that they trust input that should not be
trusted. Some use http referrer variables for security and others depend
on hidden form variables. All of these things can be easily modified by
the client. Many of the tools allow for a configuration file but often
those settings are overridden by the command-line options when in fact
the reverse should be true. Everything should default to the most secure
settings unless explicitly disabled. Finally, developers should include
good documentation on how to properly secure their application.
Certainly this is nothing more than a brief overview of a very big
problem but the solution is one that involves mailer developers, web
hosting companies, e-commerce developers, system administrators and end
users. I have only lightly touched on the vulnerabilities and solutions
yet the scope of the problem prohibits any more detail than this at
this time. I would expect the security community to research this more
and I would like to know of any other mailers that are vulnerable. I
will probably send out an addendum to this advisory that lists more
mailers as well as the actual filenames and more specific exploit
information. I would hope that web administrators realize the seriousness
of these problems and take the time to evaluate their own mailers,
whatever form they take. Many of these tools are freeware or unsupported
so the burden of fixing them is spread out among us.

Author: sozni (soznixato.net)
Thanks to: DR. Royce, tgooat, xentury, Mark, Don, Aaron

Xato Network Security, Inc. (www.xato.net) is an NT/2000 security services
company specializing in securing IIS web servers.

This document is located at:



More Keywords: CGI, Script, ASP, Perl, Form, HTML

"And its probably all Microsoft's fault"

** TO UNSUBSCRIBE, send the command "UNSUBSCRIBE win2ksecadvice"
** FOR A WEEKLY DIGEST, send the command "SET win2ksecadvice DIGEST"
SEND ALL COMMANDS TO: listservlistserv.ntsecurity.net