sockd loopback

[rieger () AT IBM COM (rieger () AT IBM COM)]

Hi folks!

I want to share with you an issue about a configuration based
vulnerability in probably many SOCKS installations. I did not
find anything about this at www.socks.nec.com, Bugtraq archive
or AltaVista engine, although the idea looks rather simple.

In connections established via the SOCKS 4 protocol the client
chooses the address of the target application server. Therefore
NEC recommends to configure sockd to deny any connections to the
internal network if used in conjunction with a firewall. But what
if the client requests a connection to the loopback (127.0.0.1)
address?
It appears that the only protection of the socks server's loopback
interface is on the CLIENT side! The socks client software connects
127.0.0.1 directly to the client's machine loopback interface.
If someone changes the appropriate lines in the socks client
code, then the client sends the request - strictly as directed
by its /etc/socks.conf - to the socks server. sockd might permit
this connection, if it has a rather liberal /etc/sockd.conf
configuration. It will then connect to the requested TCP port on the
socks server host's loopback interface.

This allows for three typical exploit scenarios:
1) The client can circumvent IP filters that protect the firewall's
   services on the network interfaces.
2) The client can reach TCP services that are listening only on the
   loopback interface.
3) The client can circumvent IP address based authentication, because
   the accessed service only sees the loopback address with which
   sockd connected instead of the real client's address.

In an experiment I tried to connect from a UNIX client on the
internal network to port 6000 on a typically configured SOCKS 4 based
UNIX firewall with IP filters and the X server running. The X server
would not serve my connection request from my client machine due to
strict host access based authentication settings and IP filter
protection.
But when I used X Windows over a manipulated socks client to connect
to the socks server on the firewall and having it access port 6000 on
127.0.0.1, I succeed to take, e.g., a screendump from the firewall
display.

I think that this is not a bug in the socks software. It is just a
weakness in typical configurations. Therefore I did not contact NEC
before - everybody who gets to know about this problem can simply
protect his socks server by adding a line to the beginning of
/etc/sockd.conf:
deny  0.0.0.0 0.0.0.0  127.0.0.0 255.0.0.0

I did not test SOCKS 5; I only suppose that this very problem still
exists.

Though I do not know if it is possible to do something bad via TCP
on multicast addresses, it might be a good idea to block these to:
deny  0.0.0.0 0.0.0.0  224.0.0.0 224.0.0.0
and maybe even the 0.0.0.0, 255.255.255.255, and external interface's
broadcast addresses.

Kind regards
Gerhard Rieger