COMMAND
NFR Web Server
SYSTEMS AFFECTED
NFR Web Server 2.0.2
PROBLEM
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/