|
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.