Two comments. - 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. ========================================== Wei Lu Email: wluat_private >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 > >
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:51:52 PDT