mod_info will tell you some of this. ie. Look for ScriptAlias lines under mod_alias.c and AddHandler cgi-script lines under mod_mime.c.
But you are fighting a bit of a lost cause here. If you allow users to upload arbitrary cgi scripts there really isn't much you can do at the Apache level. It becomes a system security issue. ie. blocking outbound port 25 connections, for example. -Rasmus On Thu, 30 May 2002, Ronald F. Guilmette wrote: > > In message <[EMAIL PROTECTED]>, > Zac Stevens <[EMAIL PROTECTED]> wrote: > > >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. > > I'll buy that. I mean it would be arrogant of me... and possibly also > just plain wrong... not to admit the possibility that I have misjudged > the true nature of the problem. > > >On Thu, May 30, 2002 at 07:45:42PM -0700, Ronald F. Guilmette wrote: > >> 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? > > Spammer exploitable. > > A more detailed elaboration of that term, as I use it, may be found here: > > http://www.monkeys.com/anti-spam/formmail-advisory.pdf > > >In the simplest case, > >you could just run 'find' across the filesystem containing the web content > >looking for "formmail.cgi" or "formmail.pl"... > > Hold on there a moment! > > The object here is to do the search _efficiently_, i.e. such that it can > be done even by very large virtual web hosting companies, on all web > servers, and every night. > > Searching the entire filesystem is out of the question. > > > 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. > > I believe that I disagree. > > There are two separate problems with what you proposed. First is the > fact that just searching for _filenames_ with the word "formmail" or > "FormMail" in them is not sufficient to find all of the bad Matt Wright > FormMail scripts that are installed on a given server. End-lusers > often install the scripts using differet names, e.g. "form.pl" or > "mail.pl" or just "fm.pl". The second problem is the notion of searching > several hunderd gigabytes of filesystem. That just isn't a viable approach, > especially given that some of the parties I'm dealing with on this issue > are already balking, even at the notion of merely scanning _just_ their > CGI-enabled directories. > > >A more thorough check would involve testing all executable ascii files, > >perhaps excluding .html/.php and variants thereof. > > Yes, and that is what is needed. > > Every plain file that has the execute bit set and that resides in any > directory for which ExecCGI is enabled must be checked (a) to see if > it is a Perl script and then (b) to see if it is a Matt Wright Perl > script. > > >> 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. > > Assume the simplifying assumption that enabling ExecCGI via .htaccess files > has been disallowed within the http.conf file. > > _Now_ tell me how to get a list of top-level CGI-enabled directories out > of httpd... please. > > >You also can't assume that only files in designated CGI directories are > >going to be problematic. > > Actually, I believe that I can, under a certain set of conditions. > > If you would like to help me flesh out what that exact set of conditions > is, then pby all means, please do. I will appreciate it. > > Understand that I am _not_ trying to build a solution to this searching > problem that will cover every possible contingency. I will be satisfied > to build a solution that I can offer to web hosting companies and then > tell them ``This will work if you carefully restrict ExecCGI capability > by doing thus-and-such.'' > > That will be adequate for my purposes. > > >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. > > OK, so where is the ``best practices'' document for Apache that describes, > in detail, exactly what webmasters must do (e.g. in the httpd.conf files) > in order to avoid exactly the kind of ``unexpected execute permission'' > problem that you have just mentioned? > > If there is no such document, then maybe it is time somebody wrote one. > (I will volunteer to write it, if other folks will provide the necessary > technical input.) > > The bottom line here is that while I accept what you say, i.e. that pro- > perly restricting ExecCGI can be tricky to accomplish, I also feel quite > sure that the Apache developer community has most probably _not_ said to > the Apache user community ``Don't even bother trying to restrict ExecCGI > capability, because you can't. Anything in your whole filesystem can be > an executable CGI, no matter what you do.'' > > I don't accept that. No webmaster in his right mind would ever accept > that. > > There certainly must be ways to properly and completely restrict ExecCGI > capability to certain specific directories chosen only by the local web > administrator. OK. Fine. Now I just need to write down what those ways > are. > > Sounds simple enough to me. > > >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. > > See above. > > I don't accept that proper CGI security is an impossibility. > > I hate to use the trite catch-phrase, but I'm forced to do so in this > circumstance... ``If we can put a man on the moon...'' > > >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. > > You said earlier that I didn't fully understand the problem. > > Now, unfortunately, I have to return the compliment. I don't believe > that you understand the problem. > > The problem isn't primarily that the versions of the Formmail script > that are installed by and approved by the local web administrators at > these sites are bad. They aren't. Those scripts are generally secure. > The problem is that big web hosting companies allow any one of their > clueless end-luser virtual web hosting customers to upload and install > _any_ arbitrary CGI script at any time into that customer's own private > CGI area. > > _This_ is the source of most of these problems... end-lusers who are out > there doing their own thing and installing crappy scripts on their own > that the local web administrator would never approve of in a million > years *if* he ever even became aware that they had been uploaded and/or > installed. > > Getting intelligent and experienced web administrators to Be Careful and > to Do The Right Thing is easy. The hard part is dealing with all of > the problems caused by all of those zillions of clueless $9.95/month > virtual web hosting customers who are doing things and installing scripts > (e.g. at 3 AM) when the intelligent and responsible web server administra- > tor isn't even in the building. > > I am working on solutions to address this latter problem. > > >This is the solution implemented at a former employer... > >... > >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 have already developed a secure version of the FormMail script, and > I have already been distributing it for some time. Also, the London > Perl Mongers group has been doing likewise. They also distribute a > secure version of the script. > > I expect intelligent web administrators to obtain one of these secure > versions of FormMail, if and when they need FormMail at all. But again, > that is not the issue. The issue is how to find the _insecure_ FormMail > scripts that those darn end-lusers have uploaded when nobody was watching > them. > > >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. > > Thank you. > > Certainly your comments about the possible extension of ExecCGI capability > via .htaccess files are well taken. That's something that I admit that > I hadn't known about, and didn't consider. But it definitely needs to > be factored in to any comprehensive solution. > > Nontheless, as I've noted above, I believe that there must certainly > be ways in which this potential problem can be adequately controlled > and restricted, and I just need to make sure that whatever solution > I offer or suggest to web administrators elsewhere includes some > appropriate statements about how to fully restrict ExecCGI capability > so that it is only extended to, and so that it can only be extended to > a fixed set of directories of the local administrator's choosing. > > > Regards, > Ron Guilmette >
