==================================================== Rhino9 Security Advisory - RPC.PCNFSD VULNERABILITES ==================================================== http://www.rhino9.ml.org (until DNS problems get straightened out) Author - horizon (jmcdonalat_private) 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.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:13:08 PDT