|
Bugtraq
mailing list archives
Re: Solaris rpcbind tricks
From: casper () HOLLAND SUN COM (Casper Dik)
Date: Wed, 22 Sep 1999 14:07:42 +0200
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
By Date
By Thread
Current thread:
- Re: Solaris rpcbind tricks Casper Dik (Sep 22)
|