Intrusion Detection FAQ: Is blocking port 111 sufficient to protect your systems from RPC attacks?

Information Security Paper: "Rpcbind and Portmapper"
David P. Reece,
Information Security Analyst
Litton/TASC Inc.
26 February 2000

This paper is written to support the requirement of the SANS Institute to demonstrate ability to perform Internet research relevant to hacking, exploits, and vulnerabilities. It was solicited by Stephan Northcutt, as an addendum to my completion of Information Assurance Foundations Level One evaluation. The assignment itself was tasked via a SANS document titled Flight School TSW Research Project by Wesley Griffin/Stephen Northcutt. With the exception of using single spacing, I have written the paper in a format preferred by the American Psychological Association (APA), and Hawaii Pacific Universities Graduate School for professional papers (those organizations prefer double spacing for readability). The method of referencing Internet web sites is in accordance with APA guidance.

The intent of the paper is to explain the security implications of a specific set of vulnerabilities in the Unix operating system relevant to port 111. To do so, I have attempted to explain the functions of the Remote Procedure Call (RPC) software. For brevity and focus, I have made my explanations only for the mildly technical. Frankly, I am not a Unix systems programmer nor expert, but rather a security analyst. It is not the intent of this paper to give more than a generalized review of the extremely technical aspects of the RPC and Portmapper process’s. As such, no effort was made to ensure total accuracy of the programming aspects of the referenced services, but rather to highlight the security implications. If there are any inaccuracies regarding the Unix system, they are my own.

The paper was created with great assistance from the Internet web sites listed in the references. Additionally, I am thankful for the assistance of Mr. Ray Cardona, my co-worker, and our local Solaris Guru at the Pacific RCERT, Ft. Shafter, Hawaii.

What is Remote Procedure Call?
Remote Procedure Call is a technique for building distributed systems, and client/server applications. Basically, it allows a program on one machine to call a subroutine on another machine. RPC is not a transport protocol: rather, it is a method of using existing communications features in a transparent way. Request For Comments (RFC) 1833 (1-3) defines specifics about Remote Procedure Call, and some of its most well know aspects that apply to security specialists, particularly Port Mapper and rpcbind. The remote procedure protocol is documented and discussed in rfc 1790 (specific to Sun rpc) and rfc 1570 has additional information.

If you use Unix servers and workstations you may be aware that there are applications that use RPC. There are NFS daemons, lock managers, and license managers. If you are a security manager, you will know that there are many know exploits against a large list of services (and more discovered every day). The first step dishonorably exploit a service is to determine if it is running on a target system. This is where Portmapper and rpcbind, and well-known port 111 come into play. This is also why the security administrators see many probes and scans of port 111.

Portmapper and rpcbind
The port mapper program maps a RPC program and version numbers to transport-specific port numbers. This program makes dynamic binding of remote programs possible. RPC server programs use ephemeral ports – thus the calling/client routine needs to access a well know port to be able to find those ports. Servers register themselves with a registrar - the port mapper (called rpcbind in Suns SVR4 and other systems using TI-RPC). This is done at port 111 for both UDP and TCP. Access to port 111 allows the calling client to query and identify the ephemeral ports where the needed server is running, and thereby make the connection to do business.

When a client makes an RPC call to a given program number, it first connects to rpcbind on the target system to determine the address where the RPC request should be sent. Basically, the active port 111 is going to have a list of all active services, and tell the requesting client were to go to connect. However, security personnel should know that under some versions of Unix, and Solaris rpcbind not only listens on the TCP/UDP port 111, but it also listens on UDP ports greater than 32770. The exact port number is dependent on the OS release and architecture. Thus, packet filtering devices, router ACL blocks, and firewalls that are configured to block access to rpcbind/portmapper at only port 111, may be subverted by sending UDP requests to rpcbind listening above port 32770. This vulnerability may allow an unauthorized user to obtain remote RPC information from a remote system even if port 111 is being blocked.

So Why DO We Care?
RPC information located at Port 111 is a place to find out where services are running. Numerous vulnerabilities exist, along with exploits ready and waiting for services such as rpcbind and rpcmountd. Network File Service (NFS) has a known rpc-update exploit, the Network Information Service (NIS) update daemon rpc.ypupdated contains vulnerabilities in how it passes commands to certain function calls. This could allow a remote attacker to trick the service into executing arbitrary commands on the system with root privileges. Additionally, client server environments that use remote program calls and port 111 to register and make themselves available, are unfortunately also listing their availability to the less-than nice people who are trying to crack your system. For the unprotected systems that have portmapper running on port 111, a simple "rpcinfo" request is adequate for the potential exploiter to obtain a list of all services running.

Fortunately, as these exploits are identified, the patches come out and the solution is made available. So, as always, keeping up-to-date on patches and releases is your best protection. However, you may also get to be the first on your block to experience a new exploit, so it is therefore prudent to strictly limit who can request the portmapper to reveal its list of available services. It has been thought that blocking access to port 111 was adequate to prevent the not-so-nice people from getting information from rpc, and while that remains a good practice, it is sadly not totally true. RPCBIND may be listening and waiting to respond on a different port! It turns out that certain operating systems versions may make rpc information available at other ports. The following is extracted from Network Associates web site, the CERT CC and BUGTRAQ advisories:

Network Associates, Inc. Security Advisory #15 June 4, 1997
This advisory addresses vulnerability in Solaris rpcbind implementations. This vulnerability can aid an attacker in gaining unauthorized access to hosts running vulnerable versions of the aforementioned software. This vulnerability allows an attacker to obtain remote RPC program information even if the standard rpcbind port (port 111) is being filtered.

Problem Description
The use of an undocumented port under Solaris 2.X for rpcbind. Solaris 2.x versions of rpcbind listen on an undocumented port in addition to port 111.

Technical Details

On Solaris 2.x operating systems, rpcbind listens not only on TCP port 111, and UDP port 111, but also on a port greater than 32770. This results in a large number of packet filters, which intend to block access to rpcbind/portmapper, being ineffective. Instead of sending requests to TCP or UDP port 111, the attacker simply sends them to a UDP port greater than 32770 on which rpcbind is listening.

Vulnerable Operating Systems and Software

The standard rpcbind shipped with Solaris 2.x systems displays this behavior. Older SunOS implementations are NOT vulnerable. Wietse Venema's replacement rpcbind for Solaris 2.x systems does not exhibit this behavior.

Fix Information

The following patches have been made available at


Carnegie Mellon and the Computer Emergency Response Team Coordination Center (CERT CC) recommend the following to tighten up the possible vulnerabilities with this issue:

Security Measures

A. Filter packets at your firewall/router.

Filter TCP port 111, UDP port 111 (portmapper), TCP port 2049, and UDP port 2049 (nfsd).

Note: Some sites may run NFS on a port other than 2049. To determine which port is running NFS, enter the following command on the machine in question: rpcinfo –p

If NFS is on a different port, then that is the port number to block at the firewall. As always, consult your vendor or your firewall documentation for detailed instructions on how to configure the ports. This measure will prevent access to NFS at your site from outside your firewall, but it will not protect you from attacks launched from your local network, behind your firewall.

B. Use a portmapper that disallows proxy access.

Be sure that you do this for every host that runs a portmapper. For Solaris, 2.x, use a version of rpcbind that disallows proxy access.

C. Check the configuration of the /etc/exports files on your hosts.

In particular:
  • Do *not* self-reference an NFS server in its own exports file.
  • Do not allow the exports file to contain a "localhost" entry.
  • Export file systems only to hosts that require them.
  • Export only to fully qualified hostnames.
  • Ensure that export lists do not exceed 256 characters.
If you have aliases, the list should not exceed 256 characters *after* the aliases have been expanded. (See CA-94.02.REVISED.SunOS.rpc.mountd.vulnerability)

  1. Use the showmount (8) utility to check that exports are correct.
  2. Wherever possible, mount file systems to be exported read only and export file systems read only.
D. Ensure that your systems are current with patches and workarounds available from your vendor and identified in CERT advisories.

  1. What is RPC? Extracted from information at CERN on 26 Feb 2000
  2. Portmapper and rpcbind information extracted 25 Feb 2000 from Connected: An Internet Encyclopedia at
  3. Securing NIS: A paper by the Auburn University College of Engineering.
  4. Managing NFS and NIS by Hal Stern. Published by O’Reilly and Associates Inc. 1st Edition June 1991.
  5. WHAT TO DO? From CERT CC security advisory, Carnegie Mellon:
  6. Various aspects of this paper were influenced by reading the BUGTRAQ archives located at: