Date: Wed, 19 Aug 1998 15:04:34 -0400
From: John McDonald <jmcdonal@UNF.EDU>
To: BUGTRAQ@netspace.org
Subject: Rhino9 security advisory - rpc.pcnfsd
Rhino9 Security Advisory - RPC.PCNFSD VULNERABILITES
http://www.rhino9.ml.org (until DNS problems get straightened out)
Author - horizon (jmcdonal@unf.edu)
Overview
--------
Repent Security Incorporated, RSI (http://www.repsec.com)
recently released a security advisory for the rpc.pcnfsd daemon. This is
available at http://www.repsec.com/advisory/0008.html. There are three
notable vulnerabilites in this network daemon that this advisory did not
address. Rhino9 is releasing this advisory with the intent of alerting
vendors and free operating system developers/maintainers of other
problems in the daemon that should also be addressed.
Problem
-------
There are three other confirmed security holes present in the
rpc.pcnfsd daemon that have not been previously addressed.
Vulnerability #1: pr_cancel - Most implementations of rpc.pcnfsd
As pointed out in the Repsec advisory, the suspicious() function
does not check for several shell meta-characters, which allows the
newline, and on some operating systems, the '/' character to be passed.
This allows for the exploitation of the run_ps630 system() call, as
documented in the advisory. However, this oversight in the suspicious()
function also allows for an attacker to manipulate the pr_cancel()
function to gain access to the machine. Specifically, an attacker will
have to invoke pr_cancel with a valid printer name, a valid user name,
and a printer id containing the crafted exploit string. The printer id
will be passed through the suspicious() function, and then run through a
shell in the su_popen() function. As far as obtaining a valid printer id,
some implementations unilaterally accept "lp" as a valid printer, but
this is not a concern because the attack can request a list of the valid
printers with the pr_list RPC call. As the third vulnerability addresses,
it is easy for an attacker to get a list of valid usernames out of
rpc.pcnfsd.
Vulnerability #2: get_pr_status - OpenBSD is the only confirmed
vulnerable OS
The get_pr_status function uses popen() directly, as opposed to
calling the su_popen() function. The OpenBSD implementation of rpc.pcnfsd
does not check if the supplied printer name is a valid printer; it only
checks if the name is suspicious. Thus, a printer name can be provided
such that remote commands can be executed as root.
It is very important to note that the OpenBSD team is well aware
of the problems with rpc.pcnfsd and that this vulnerability is in no way
an indication of any oversight or negligence on their part. The man page
for rpc.pcnfsd on OpenBSD gives a very strong warning not to use the
program, because of numerous known security flaws. Their auditing efforts
have wisely been placed in the more critical programs.
Vulnerability #3: mapid / auth - All implementations are vulnerable
This is a more difficult problem in scope because it addresses
the inherent functionality of the daemon. Any attacker can use the
mapid() functionality of rpc.pcnfsd to retrieve a list of the usernames
on a system. The far more serious hole is that an attacker can use the
authentication functionality to attempt to guess passwords. These
password guessing attempts are not logged in any implementation we have
looked at. The only logging that occurs is when the attacker succesfully
guesses a password. Upon this occurance, a single entry is placed in
wtmp. It is easy to write a program to attempt to brute force passwords,
working from a list. Also, there are no slowdowns built into the program
to prevent rapid brute force attacks. Some implementations do not allow
logins of UID's below a certain number.
This functionality of rpc.pcnfsd has never previously been
discussed on bugtraq, excluding a brief post that presumably
went un-noticed. This post is available at
http://geek-girl.com/bugtraq/1996_2/0151.html.
Impact
------
The first vulnerability will allow a remote user to obtain
non-root access to most machines running rpc.pcnfsd. Notable exceptions
are NetBSD, which has a very strict suspicious() function, and later
versions of the Solaris package, which use single quotes around the
arguments in it's popens. Also, some machines will allow remote root
access, but most likely none of the current implementations.
The second vulnerability will allow a remote attacker to obtain
root access to an OpenBSD machine and possibly older machines running BSD
based implementations of pcnfsd.
The third vulnerability will allow an attacker to gain valuable
information about a machine. Furthermore, if the machine has unpassworded
or weakly passworded accounts, they can be easily guessed, with very
little logging of malicious action.
Vulnerable Platforms
--------------------
We have not done research to the level that we would like
regarding vulnerability in different platforms. This information is
likely to be inaccurate, and we welcome corrections. rpc.pcnfsd appears
to be exist by default on HPUX, Irix, AIX, Digital Unix, Slackware,
OpenBSD, and NetBSD. It also appears to run by *default* on Irix and some
HPUX distributions. pcnfsd is available as a package under other Linux
distros, Solaris, SunOS, and FreeBSD. All implementations are open to the
third vulnerability, which is an inherent risk in running the program.
>From experiments, we are somewhat certain that both NetBSD and the latest
Solaris versions are immune to the first two vulnerabilities. Also, they
appear to be immune to the remote vulnerability detailed by the Repsec
advisory. Also, the runps630 vulnerability mentioned in the Repsec
advisory does not affect the BSD distributions due to code fixes made to
address the CERT advisory regarding a similair problem. HP/UX, Irix, AIX,
Slackware, OpenBSD, older Solaris, and SunOS appear to be vulnerable to
all of the holes discovered.
Solution
--------
Don't run rpc.pcnfsd. If you have to run it, be sure you fix the
code or get a new version.
The first two vulnerabilites can be addressed by developers by
adopting NetBSD's solution or Sun's solution. The slackware patches
provided in the Repsec advisory are also appropriate.
The third vulnerability could possibly addressed by placing a
pause before the return of authentication information, or limiting the
scope of rpc.pcnfsd's functionailty. Regardless, there needs to be
logging of authentication attempts and failures.
Other Comments
--------------
There are some other potential holes in the daemon that have not
been confirmed by us. Namely, most of the functions utilize unbounded
string copies. This may or may not be exploitable, depending on the string
length limitation imposed by the xdr encoding/decoding.
