Modified Portmapper/rpcbind
Two issues: finding the port, and relaying requests.
Modified code applies tcpwrapper rules to port locate requests. But hackers can still search for the port.
Unmodified code forwards requests - which then appear to have been issued locally. Modified code does not relay normal requests, so the service sees their origin IP address - but this doesn’t help if the service itself doesn’t care.
Beware YP/NIS servers! And export-anywhere f.s.
R-Series commands are a PAIN, and .rhosts a RISK.
http://lheawww.gsfc.nasa.gov/~srr/prog_forum.html
Notes:
The modified Portmapper/rpcbind programs apply rules from the tcpwrapper’s configuration file in order to prevent blocked addresses from asking for a portmapped service. It must be clearly understood that this only prevents them from using portmapper/rpcbind: they can still go hunting for the service itself, by scanning the active port numbers in the likely range.
Portmappers have a feature whereby they can forward a request on to the requested named service; but the service then sees the request as coming from a local source, losing the ability to have the service detect where requests are coming from. The modified version has been tamed in this respect.
However, you still must understand that most services aren’t programmed to worry about where the request comes from.
And it appears that YP/NIS servers are happy to hand over the jewels to anyone who asks the right question. The “ypx” program seems to be in every hacker’s toolkit.
Exported filesystems that are mountable by anyone are another potential risk.
The R-series commands are bad enough already, but the fact that a lazy user could be tempted to throw themselves open with “+ +” is awful.
Read http://lheawww.gsfc.nasa.gov/~srr/prog_forum.html and weep!
By the way, X Windows security wasn’t an issue in our incident, but should never be forgotten as a potential exposure.