>While this is hardly a new bug and the dangers of not having proper >anti-spoofing > checks in your perimeter router/firewall has been discussed over and >over in the > past years I believe it might be worth a post to bugtraq. >The following can be taken as an example of how a combination of bugs, >protocol >flaws and bad coding practices can bring to life new incarnations of >ancient security >problems. >This was discussed months ago with Oliver Friederichs and Theo de Raadt >over >considerable amounts of beer, since then i didnt have time to >investigate further till last week. > Sebastian R. Wain <swain@core-sdi.com> provided a lot of his time >testing and > figuring out the detailst. Sorry for not mailing this to bugtraq earlier, but only to Ivan Arce in private; we came to the conclusion that the outlined attacks only work on unpatched Solaris 2.6 and before. The relevant Sun bug is: 4070261 predictable RPC XIDs when forwarding CALLIT RPCs The following patches that have been around for quite some time fix this problem: 102034-05: SunOS 5.3: usr/sbin/rpcbind patch 102070-06: SunOS 5.4: usr/sbin/rpcbind patch 102071-06: SunOS 5.4_x86: usr/sbin/rpcbind patch 104331-07: SunOS 5.5.1: /usr/sbin/rpcbind patch 104332-07: SunOS 5.5.1_x86: /usr/sbin/rpcbind patch 104357-06: SunOS 5.5: usr/sbin/rpcbind patch 104358-05: SunOS 5.5_x86: usr/sbin/rpcbind patch 105216-03: SunOS 5.6: /usr/sbin/rpcbind patch 105217-03: SunOS 5.6_x86: /usr/sbin/rpcbind patch Solaris 7 has this bug fixed. The new code added checks that replies received not only have matching XIDs but also have matching return address. > 1. Attacker sends a spoofed PMAPPROC_SET call to register a service >named > "bogusd" on the any available port on localhost. > > src addr : 127.0.0.1 > dst addr : bouncing.host.com > dst port : 111 > program : rpcbind > procedure: PMAPPROC_SET > data : BOGUSPROG,BOGUSVERS,BOGUS_PORT,etc Should work and creates a UDP registration; note that it's pretty easy to prevent spoofed 127.0.0.1 packets from coming through in Solaris: ndd -set /dev/ip ip_strict_dst_multihoming 1 (A packet coming in with a local destination address but over the wrong interface will be dropped) > 5. attacker sends rpcbind a NON-spoofed CALLIT call to BOGUSPROG > > src addr : attacking.host.com > dst addr : bouncing.host.com > program : rpcbind > procedure: PMAPPROC_CALLIT > data : BOGUSPROG,BOGUSVERS,BOGUS_PROCFOO,etc > > This will generate a RPC call from rpcbind on the bouncing host > to BOGUS_PROGRAMNUM on the bouncing host as follows: > > src addr : bouncing.host.com > src port : rpcbind_forwarding_port > dst addr : bouncing.host.com > dst port : BOGUS_PORT > program : BOGUSPROG > procedure: BOGUS_PROCFOO > XID : xid_j+1 > > 6. attacker sends a spoofed call to mountd's RPCMNT_MOUNT procedure > with : > > src addr : bouncing.host.com > src port : rpcbind_forwarding_port > dst addr : attacked.host.com > dst port : MOUNTD_PORT > program : MOUNTPROG > procedure: MOUNT_PROCMNT > XID : xid_j+1 With the patch, the reply to this request should now fail because MOUNTD_PORT != BOGUS_PORT (in most cases, the rpcbind callit request will be done using connectionless TLI; you'll be comparing a TLI address w/ an IP address and no amount of spoofing can make it match) > 7. mountd on the attacked host replies to this request with > the proper filehandle, rpcbind will get the reply, match it to > a previous CALLIT request, and pass it back to the caller. This step should fail in systems with patches later than march '98. > The attacker has just grabbed a filehandle, bypassing the > restrictions imposed in rpcbind for CALLIT calls. NFS file handles as returned by mount are not as useful as before; you will need to spoof all NFS requests through rpcbind (at least, those you want to have a reply for) > 1. XIDs of the forwarded calls are predictable > > Assuming that our RPC calls to rpcbind, PROC_CALLIT are the first > CALLIT requests received by the bouncing host since it was booted > (this is a fair assumption) and knowning or being able to aproximate > > the uptime of the target host, the XIDs that rpcbind will generate >for > the forwarded requests can be easily predicted. This may still be the case. > 2. Theres no check for the src address and port of the replies to > forwarded calls to match the dst address and port of the original > call. This check has been implemented some time ago. > rpcbind does not check that RPC reply messages, received on the > socket used to forward CALLIT requests, have a valid source address, > > port, prognum, progvers, etc. The current implentation checks the endpoint address; since the RPC protocol replies do not include the procedure and version number, it is impossible to check whether the proper function replied or not. Casper
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:04:49 PDT