Re: portmapper dangers

[casper () holland Sun COM (Casper Dik)]

> The dangers, according to the code changes I saw, are that the
> portmapper will accept set and unset requests from other than the local
> machine, and that it will accept set and unset requests for reserved
> ports from clients not themselves running on reserved ports.  I'm sure
> most readers of bugtraq will immediately see the dangers inherent in
> these lacks of checking.  (The code I saw counts port 2049, the default
> NFS port, as reserved even though it is not in the reserved port space.
> I suppose one could argue whether this should be done.)

Is this just the case of faking the from IP address?  I'm not
sure if there's a way around that; UDP is easily faked. Standard
portmap code has had checks for some time to disable unsets from
remote hosts and unsets for reserved ports from non reserved ports
but older versions did suffer from the problem.

There's no way, it seems to me, that portmap can protect itself from spoofed
udp packets. It can't discern locally and remotely send udp packets
without some external help (from kernel or external packet filters)

Rpcbind, the TI-RPC (transport independent)  version of portmap,
should not be vulnerable as it will only allow unsets from the
corresponding service owner.  (Which can be gotten at when using the
local transport with help of the kernel, i.e., user processes can't
fake them, you can't fake local transport calls remotely)

Old code which uses old portmap calls will have its services registered
as from an "unknown" source and the old unsafe semantics apply.

(Try rpcinfo <sunos4host> vs rpcinfo <solarishost>" for good measure,
note that you need to be on a host with rpcbind for "rpcinfo" to work
like this)

Casper