Hi Ronald,
Let me preface this by noting that I agree with your goals, however I believe that you may not have considered the nature of the problem in sufficient depth. On Thu, May 30, 2002 at 07:45:42PM -0700, Ronald F. Guilmette wrote: > Most sites and web hosting companies _do_ want to eliminate these exploit- > able FormMail scripts from their web servers, but when you are a big web > hosting company with thousands of virtually-hosted web sites, the task of > just finding the bad scripts in your filesystem isn't terribly easy. In > fact in can get downright convoluted. > > The first step in finding all such scripts however may often be the most > difficult one. That first step consists of simply gathering into one > big list a list of all of the CGI-enabled directories on the local web > server. Once such a list has been compiled, other standard UNIX tools > such as `find' and `file' and `grep' and be set to work, plowing through > all of the files in those (CGI) directories and finding all of the bad > FormMail scripts. How are you defining "bad FormMail scripts" here? In the simplest case, you could just run 'find' across the filesystem containing the web content looking for "formmail.cgi" or "formmail.pl" and checking those found against a list of known good/bad versions. This doesn't require any specific knowledge of the Apache configuration in use, and is an entirely viable approach even on filesystems of several hundred gigabytes. A more thorough check would involve testing all executable ascii files, perhaps excluding .html/.php and variants thereof. > But seriously, is there already a way to do what I need to do with the > Apache server? Looking at the command line options on the man page for > httpd, there doesn't seem to be an option to request httpd to just parse > the config file, list the CGI directories, and then exit. But that's > exactly what I need. It isn't possible in the generic case. Apache allows many aspects of the configuration to be modified by the inclusion of ".htaccess" files beneath the DocumentRoot of the web server. Unless Apache has been configured not to allow the ExecCGI option to be overridden, you would need to parse both httpd.conf AND every .htaccess file on the filesystem. Apache itself does not do this at startup - it is done only as required. > P.S. Note that FormMail is far from the only dangerous CGI script that > a big web hosting company might find that some of its less-clued end lusers > may have uploaded and installed into CGI-enabled directories. And the > overall comprehensive search process that I'm trying to develop could > be (and arguably should be) applied to searching for other dangerous CGI > scripts too. You also can't assume that only files in designated CGI directories are going to be problematic. There's a long history of people using all sorts of redirection and other techniques to access/execute things that they shouldn't be able to. This does, admittedly, involve far more effort (and good luck) than the straightforward formmail abuse you're concerned about. It should be apparent at this point that what you're looking at here is a reduction of the abuse of formmail & etc, as it is almost impossible to stamp out entirely. In this particular example, the best solution is for the web host to replace the sendmail binary with something which performs more rigorous checking of its input and, ideally, tags outbound messages with identifying information. This is the solution implemented at a former employer - the sendmail replacement checks that the From: address is valid and sane and writes a Received: header which includes information which can be used to identify the VirtualHost responsible for generating the message. This also removes the ability for poorly-written PHP scripts and the like to be abused in a similar manner. Although the script was developed in-house (and, unfortunately, cannot be released) I believe there are open-source alternatives available to accomplish the same ends. I hope these thoughts provide you with a different perspective to consider, and I wish you well in your efforts to reduce the amount of spam on the Internet. Cheers, Zac
