Bugtraq mailing list archives
Lotus Notes HTTP cgi-bin vulnerability: possible workaround
From: die.spammer.die () E-WARENESS BE (Bram Kerkhof)
Date: Wed, 22 Dec 1999 09:38:59 +0100
The buffer overflow problem in notes as mentioned by Alain Thivillion can be worked around if you don't use cgi-scripts at all, or are prepared to do a bit of work for all the scripts that are on the server. The procedure (Lotus Notes knowledgebase) : ------------------------- The workaround in versions prior to 4.6.1 is to create a URL redirect in the DOMCFG.NSF database that redirects any anomalous CGI requests to another URL. Since any non-existent CGI calls can cause this error, the following workaround is suggested. * If the customer does not require the use of any CGI's, then the entire /cgi-bin directory can be redirected to another URL (a Notes database, or html file). If any "/cgi-bin" requests are made, they will be directed to this URL and are not processed as CGI. * If the customer does require the use of CGI's the following setup will be required: 1) In the HTTP section of the Server Document, change the "CGI URL path" field to a different URL path. This does not require a change for the "CGI directory" field, such that the location on the hard drive for CGI's will remain the same. Only the URL which invokes CGI's will be altered. Example: The default CGI URL path is "/cgi-bin"; change this to "/scripts/cgi-bin". Now, whenever a /cgi-bin request is made, it is recognized as a URL instead of a CGI. 2) Create a URL Redirect document in the DOMCFG.NSF for each specific CGI that resides on the server. Specify the incoming URL path as "/cgi-bin", and the redirection URL as "/scripts/cgi-bin". Example: A customer has a CGI named "Xrun.cgi" in the domino/cgi-bin directory. Regularly, any requests to execute the CGI would come in as "http://hostname/cgi-bin/Xrun.cgi". This URL request is redirected to "http://hostname/scripts/cgi-bin/Xrun.cgi", where Domino will recognize it as a CGI, and run the script. In this case, the "/cgi-bin" URL itself is not recognized as a CGI request. It is only the redirection to "/scripts/cgi-bin" that will cause the Domino server to process it as a CGI script At this point, any generic requests for CGI's using "/cgi-bin" will not be recognized as CGI. Instead, the Web server will search for a comparable filename, returning "Error 404- file not found" since it is not capable of finding such a URL. The customer can now customize the error message to indicate that the requested CGI does not reside on the server. The above configuration is designed to accomplish the following: * Since the current Domino 4.6 Server code may crash any time a non-existent CGI is requested, the potential to run non-existent CGI's must be removed. By this configuration anomalous CGI requests are not recognized as CGI scripts, and Domino will not attempt to run them. * The CGI URL path is altered so that only CGI's using the URL "/scripts/cgi-bin..." will be recognized as CGI's. The administrator then creates a URL redirect document for each present CGI that redirects any valid URL requests using the syntax "/cgi-bin..." to the URL "/scripts/cgi-bin...". The Domino Server will then invoke the CGI script. This will avoid the Domino Server attempting to run a CGI that is not present on the server, running only valid CGI's. * Since the URL redirect does not display the redirected URL to the browser, end users need not ever know the true URL path to invoke CGI scripts. This further protects the site from unscrupulous web clients deliberately attempting to crash the server by requesting to invoke a non-existent URL. Such a user would need to know the exact URL path to issue for the server to recognize it is a request for a CGI, and would have no way to determine this URL under a secure site. -------------------------- It means that you have to set your cgi-bin path to something which is, as Alain stated, unguessable, but has the advantage of not disclosing this path to the visitors of the site and maintainig the possibility to run CGI's if needed. The full knowledgebase article is available at http://www.support.lotus.com/sims2.nsf/0/6ecb87e6e6820b008525659f0080d40c?Op enDocument Bram Kerkhof -- I'll do the stupid things first, then you shy people follow. [Zappa] Switch my first name with the obvious to email me.
Current thread:
- Re: [w00giving '99 #11] IMail's password encryption scheme, (continued)
- Re: [w00giving '99 #11] IMail's password encryption scheme Steven Alexander (Dec 21)
- Warning to Bugtraq posters. Steven Alexander (Dec 22)
- Re: Warning to Bugtraq posters. Richard M. Smith (Dec 23)
- Re: [w00giving '99 #11] IMail's password encryption scheme Mikael Olsson (Dec 22)
- Re: [w00giving '99 #11] IMail's password encryption scheme Steven Alexander (Dec 22)
- Re: [w00giving '99 #11] IMail's password encryption scheme Benjamin Congdon (Dec 22)
- Re: [w00giving '99 #11] IMail's password encryption scheme Steven Alexander (Dec 23)
- FYI, SCO Security patches available. Aaron Sigel (Dec 23)
- Local / Remote GET Buffer Overflow Vulnerability in ZBServer 1.5 Pro Edition for Win98/NT Ussr Labs (Dec 22)
- Warning to Bugtraq posters. Steven Alexander (Dec 22)
- Lotus Notes HTTP cgi-bin vulnerability: possible workaround Bram Kerkhof (Dec 22)
- Re: [w00giving '99 #11] IMail's password encryption scheme Steven Alexander (Dec 21)