>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 <[EMAIL PROTECTED]> 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
