[10981] in bugtraq
Re: sockd loopback
daemon@ATHENA.MIT.EDU (Wei Lu)
Fri Jul 9 04:46:56 1999
Mime-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-Md5: AWNqt/EA/urScWSMWEqWpQ==
Message-Id: <199907081448.JAA26124@jeckle.syl.dl.nec.com>
Date: Thu, 8 Jul 1999 09:48:44 -0500
Reply-To: Wei Lu <wlu@syl.dl.nec.com>
From: Wei Lu <wlu@SYL.DL.NEC.COM>
X-To: bugtraq@securityfocus.com, socks@socks.nec.com, rieger@at.ibm.com
To: BUGTRAQ@SECURITYFOCUS.COM
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: wlu@syl.dl.nec.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
>
>
