|
Vulnerability NFR Web Server Affected NFR Web Server 2.0.2 Description Following is based on Network Associates Security Advisory. An implementation fault in the Network Flight Recorder network forensics system makes it possible for a remote attacker to obtain system management privileges on boxes running NFR in a standard configuration. This problem has been confirmed and is known to be exploitable on hosts running Network Flight Recorder's NFR 2.0.2-Research release. Because source code is publicly available for this software, it is possible to confirm vulnerability to this problem by inspecting the source used to build an installation of NFR on an arbitrary host. The Network Flight Recorder custom web server is used to present an HTTP front-end to the NFR system. By default, the web server is called "webd", and is bound to TCP port 2001. In the absence of external network access control, arbitrary remote attackers can conduct transactions with the NFR web server. Due to an implementation fault in "webd", it is possible for a remote attacker to formulate an HTTP transaction that will cause the web server to overflow an automatic variable on the stack. By overwriting activation records stored on the stack, it is possible to force a transfer of control into arbitrary instructions provided by the attacker in the HTTP transaction, and thus gain total control of the web server process. In a default installation, "webd" runs as the unprivileged "nfr" user. Thus, this attack does not grant an attacker immediate system management capabilities. However, in a standard installation of NFR, program binaries that are run by the superuser are owned by the "nfr" user. An attacker that has gained access to the "nfr" user via the web server can backdoor these files to gain root privileges when NFR is restarted. Source code for the NFR system is publicly available under license from the NFR web site. NAI's advisory makes reference to the source code in the NFR 2.0.2 Research release from Wed Jan 27 1999. The vulnerability discussed in this advisory occurs as a result of "webd"'s processing of the HTTP "POST" command. POST requests are handled in "nfr/webd/cmdpost.c". Regardless of the configuration of the NFR web server, the vulnerable POST handling code is exposed to remote attackers. The HTTP commands handled by the NFR web server are listed in the command table, which is located in "nfr/webd/ctab.c". The command table maps HTTP command names to function handlers. The function handler for "POST" commands which reference programs in the root directory of the web server is defined as "cmd_postbltin()", which is defined in "cmdpost.c". In order to process the POST command, the function handler attempts to read MIME headers for the POST data from the HTTP client. This is handled in "getpostdata()", also defined in "cmdpost.c". Among the headers recognized by the code is "Content-length", which defines the amount of data the client is sending the server in the POST transaction. Unfortunately, the MIME header recognition code does not sanity check the value given as the Content-length. It is possible for an attacker to specify an arbitrary Content-length header, which will be trusted by the server as valid input. After parsing MIME headers, the web daemon attempts to read as many bytes as the client specified in the Content-length header into an 8k buffer, named "buf", which is an automatic buffer in cmd_postbltin(). If the attacker specifies more than 8192 bytes of data in the header, the additional data will overwrite the stack frame for cmd_postbltin(), allowing the attacker to take over the web daemon process. Note that in some operating systems, causing a single read() to return more than 8192 bytes is difficult; this problem may not be easily exploited on these systems. This problem is known to be exploitable against 4.4BSD Unix operating systems running NFR. This is the recommended NFR platform. Solution It is recommended that vulnerable users of NFR contact NFR immediately for a patch to this problem. NFR has announced the release of a patch that will correct this problem. It's patch number 2.0-p3 and it applies to product NFR Version 2.0.2 Research. The patch is available as a patch file which can be applied to NFR Version 2.0.2 Research, and as a complete distribution. Both versions are available from http://www.nfr.net/downloads/