Re: Details on Sidewinder RPC proxy support?

[Ivan Arce <core.lists.firewall-wizards () core-sdi com>]

"Lee (Lockdown) Hughes" wrote:

> I'm new to this list, but I'd advise your client not to map client or server
> rpc
> request through there filewall. You asking for trouble, if you can push them
> down
> either a Ipsec vpn route, or some of IP tunneling system, then do it.

this is complete nonsense
in fact tunneling RPC over IPSEC or any VPN mechanism will only make things
worse
than proxying it.
Tunneling RPC will just move the threat  to the other end of your VPN tunnel.
The idea of proxying RPC is that the proxy is able to inspect the payload,
 in this case RPC headers, XDR encoded data AND application/program specific
data.
I sincerely dont see a way of doing this reliably and without false positives
and
false negatives in the case of detection of attacks for all RPC in general.
Granted, maybe the proxying mechanism on a firewall would just have to
control which RPC programs and procedures are reachable from an external
network.
The problem a see with this approach is that allowing connections on a
per prognum/procedure will open up the internal RPC servers to attackes that
rely on protocol design flaws, interaction between different RPC program and
payload data. And a simple RPC proxy can't stop this.

SCC's paper says:
" Sun RPC proxy
  The Sun RPC proxy mediates requests from an RPC client to a server’s
portmapper process.
  The Sun ONC RPC format is supported. This feature will allow client/server
applications to
  communicate securely through the firewall."

That is obviously not enough to allow RPC communications across a firewall. And
actually, the only
need for a client WRT portmapper/rpcbind is to be able to perform a
PMAPPROC_GETPORT
request (and maybe, only maybe PMAPPROC_CALLIT and PMAPPROC_DUMP), but after
that the client usually comunicates directly with the RPC program on the server
side, so how
is this proxy any good? Does it open up holes on the firewall as it monitors
GETPORT requests
to the inside portmapper?

And. what about callbacks on the RPC  servers?

> RPC is a very complex procedure, and has many holes actaully within the
> layer 7

I'd really like to see how RPC,XDR and application specific data relates to
the OSI model to have a more clear understanding of where this holes are

> part of it, buffer overflows, no parameter checking, possible one of the
> most
> unhacked and unknown area's on the machine! Hackers like virgin.

I beg to differ...
portmapper/rpcbind bugs have been known and exploited for years, a vast load of
rpc related bugs has been published in the past in bugtraq and other lists, lets
not forget
that cmsd, statd, automountd, nisd, ypserv,ypbind,mountd,nfsd,etc. are ALL of
them RPC
programs.

As for the unexplored part of it, i dunno, i'd guess that besides checking each
rpc program
the interesting thing would be to audit the basic building blocks; RPC
(ONC|TLI|XLI|DCE?)
and the XDR layer.

-ivan


--

"Understanding. A cerebral secretion that enables one having it to know
 a house from a horse by the roof on the house,
 It's nature and laws have been exhaustively expounded by Locke,
 who rode a house, and Kant, who lived in a horse." - Ambrose Bierce

--------------------------------------------------------------------------------------------

 Iván Arce <ivan () core-sdi com>
 Presidente
 CORE SDI S.A.
 Pte. Juan D. Peron 315 4to UF17 (1394) Buenos Aires, Argentina.
 TE/FAX: +54-11-43-31-54-02 +54-11-43-31-54-09
 PGP fingerprint: C7A8 ED85 8D7B 9ADC 6836  B25D 207B E78E 2AD1 F65A
--------------------------------------------------------------------------------------------