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.