|
Brought to you by:
Suppliers of:
|
|
|
| |
The iPlanet web server depends on user-supplied data to construct response headers when redirecting a request. The "Location:" header must be fully qualified, so iPlanet bases the host portion on the "Host:" header in the request to facilitate virtual server environments.
This allows an attacker to control the content of the response "Location:" header. Additionally, an attacker can fill the "Host:" header with characters that will be automatically URL-encoded by iPlanet before response handlers are called, thus tripling the amount of possible data returned in the "Location:" header.
It is theorized that when iPlanet reads the request headers from pooled memory, a pointer handling error results in the unintentional retrieval of data on the heap written by other server functions. |
| |
Credit:
The information has been provided by at stake Advisories.
|
| |
Vulnerable systems:
iPlanet Web Server Enterprise Edition 4.0
iPlanet Web Server Enterprise Edition 4.1
Immune systems:
iPlanet Web Server Enterprise Edition 4.16
Netscape Enterprise Server 3.6x
The iPlanet Web Server Enterprise Edition is a commercial web server used by organizations to serve up static web content, as well as deliver dynamic, personalized content retrieved from an application server or database backend. It is one of the three most popular web servers found on the Internet today, and a large number of secure, transactional application sites use the iPlanet Web Server as their front-end web server.
The iPlanet Web Server has an implementation flaw that allows any remote user to retrieve data from the memory allocation pools on the running server. The retrieved data usually consists of fragments from previous HTTP requests and responses, including session identifiers, cookies, form submissions, usernames and passwords, etc.
In the example of a home banking application deployed by a financial institution, this would grant an attacker access to any user accounts that logged in within some reasonable time before the attack was launched. Supplied with a valid session identifier, the application has no way of differentiating between the legitimate user and the attacker before executing transfers, bill payments, equity trades, etc. If persistent authentication credentials are used, in the form of a "remember my password" or "autologin" feature, these credentials could be used at any point in the future to access the user's account.
This is a buffer overflow vulnerability in which improper handling of response header values permits access to unauthorized data. This vulnerability can be used by an attacker to retrieve authentication and authorization credentials or to hijack existing user sessions. The vulnerability can be exploited without crashing the server and may occur within an SSL tunnel, making it extremely difficult to detect. Requests can also be routed through anonymizing proxies making it difficult to trace the request's origin.
Under certain conditions, this vulnerability may also be used as a denial of service attack.
Detailed description:
iPlanet web servers by default will send a 302 "Moved Temporarily" response when a client requests a directory without a trailing slash. Thus, any user can force this behavior by manipulating the request "Host:" header.
It is a simple matter for an attacker to send in requests that consistently return reliable, useful data. Certain lengths will cause a segmentation fault in the server process, but the uxwdog process restarts it automatically. A valid 302 is logged in the access logs, but there is no indication of an attack as it is extremely rare for a web server to log all incoming HTTP request headers. When wrapped within an SSL tunnel, IDS does not have the opportunity to detect the attack unless the sensor is deployed between an SSL stripper and the web server.
At this time, it does not appear possible to exploit this vulnerability to execute arbitrary code on the web server.
Using the specific request lengths that cause a server thread/process to crash, this vulnerability can be used in a denial of service attack against the web server. If, on a Windows platform (NT or 2000), the service is not configured to auto-recover, or if, on a *nix platform, the kill requests are generated faster than the uxwdog process can respawn, an effective denial of service may result.
Vendor response:
iPlanet has acknowledged that the above described problem exists and that it affects its iPlanet Web Server 4.x product line. iPlanet has committed to addressing this vulnerability by issuing a fix on April 16 to be made available in two formats simultaneously: an upgrade, iWS 4.1 SP7 and an NSAPI module that will shield the earlier versions of the server from the problem. These fixes, which will wholly mitigate the risk posed by this vulnerability, are available at:
http://www.iplanet.com/products/iplanet_web_enterprise/iwsalert4.16.html
With implementation instructions and information on which fix is most appropriate for which cases.
Solutions:
There are a number of things that can be done to partially or wholly mitigate the risk posed by this vulnerability. The following are some examples. The reader is encouraged to understand their environment and business needs and base their solution around those.
* You should upgrade to the iPlanet Web Server 4.1sp7 version if possible.
* Use or write an NSAPI module similar to the sample provided to inspect incoming HTTP request headers. The module could be run as the very first NameTrans directive in the default object so that it will apply to all incoming requests. The sample allows a maximum length for the "Host:" header to be specified in the obj.conf file, will log an error if it is exceeded, and will send a "440 Go Away Kid" response to the client.
(It is important to note that the included NSAPI module will not protect the server if any application code performs a redirect based on query-string or POST'ed data.)
NSAPI Data Validation Module:
Usage:
In [server-root]/[server-instance]/config/obj.conf:
...
Init fn="load-modules" shlib="[path to libs]/long.so"
funcs="bounds_check"
<Object name=default>
# Make sure this function is the first to be called
NameTrans fn=bounds_check maxlength=100
...
----- BEGIN -----
#include "nsapi.h"
static int max_req_len = 0;
NSAPI_PUBLIC int bounds_check(pblock *pb, Session *sn,
Request *rq) {
char *temp;
max_req_len = atoi(pblock_findval("maxlength", pb));
temp = pblock_findval("host", rq->headers);
if (temp != NULL) {
if (strlen(temp) > max_req_len) {
log_error(LOG_SECURITY, "bounds_check", sn, rq,
"Overly long host header (%d bytes)...
aborting.",
strlen(temp));
protocol_status(sn, rq, 440, "Go Away Kid");
return REQ_ABORTED;
}
} else
return REQ_NOACTION;
}
----- END -----
* Terminate the SSL session on a device before the iPlanet server and install an IDS sensor to monitor the clear-text traffic. Write a filter to detect abnormally long HTTP request headers.
* Terminate the SSL session on a reverse-proxy that performs data validation on all HTTP request headers. If a specified length is exceeded or a pattern matches, log, alert, and send a warning down to the client.
* Downgrade to Netscape Enterprise Server 3.63. www.iplanet.com is currently running 3.63.
|
|
|
|
|
