TUCoPS :: Unix :: General :: socks3-1.htm

Vulnerability
 sockd
Affected
 Those using socks
Description
 Gerhard Rieger found following. 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.
 4) Scenario where the (socks) proxy itself is listening on all
 interfaces, loopback as well as external. Connect to
 proxy, authenticate with proxy, socks_connect to localhost,
 authenticate, socks_connect, wash rinse repeat. In most
 cases this will result in some form of resource exhaustion,
 or as in some cases with Wingate's most recent version of
 SOCKS, server death and even OS death (hang or blue
 screen). Also, this isn't just limited to loopback; you're
 actually more likely to accomplish this form of DoS by
 reconnecting to the proxy's external IP. And, even if you
 block these kinds of "looped" connections, you can easily
 bounce between two SOCKS servers to accomplish the same
 attack. Of course, for any of the above to be an easily
 perpetrated attack, the SOCKS server has to allow AUTH_NONE
 (method 0x00) authentication. Unfortunately, by default
 most SOCKS servers do (although, IIRC Dante is not one of
 these).
 In an experiment 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 connection request from client machine due to
 strict host access based authentication settings and IP filter
 protection. But when 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, tester succeed to take, e.g., a
 screendump from the firewall display.
Solution
 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
 The reference implementation of socks5 handles the situation
 properly. More importantly, SOCKS users must configure their ACLs
 properly. Having a line like "permit - - - - - - -" is asking for
 security problems.