Vulnerability

    Squid

Affected

    Those running Squid 2.2.STABLE5 and earlier

Description

    Oezguer Kesim found following.  He found a security bug in  squid,
    a  web  proxy  cache,  freely available at http://squid.nlanr.net/
    Here you find the short Buglog-entry as shown at

        http://squid.nlanr.net/Versions/v2/2.2/bugs/

    Please note that the bug applies whenever a external authenticator
    is used.  After  decoding the base64 encoded  "user:password" pair
    given by  the client,  squid doesn't  strip out  any '\n'  or '\r'
    found in the resulting string.  Given such a string, any  external
    authenticator  will  receive  two  lines  instead of one, and most
    probably send two results.   Now, any subsequent  authentification
    exchange  will  has  its  answer  shifted  by  one.   Therefore, a
    malicious user can gain access to sites he or she should not  have
    access to.

    Assumptions:
    ~~~~~~~~~~~~
    1) You  use  plain  squid-2.2-STABLE5  or  below.  Also,  external
       authentification is active using a some external authentication
       program, which basically follows the implementation  guidelines
       given on the squid-webpages.

    2) Your ACL's  for external authentication  apply often enough  so
       that external authentificatoin actually happens maybe every  20
       seconds   to   20   minutes.    This   also   depends  on  your
       password-cache settings.

    3) In general, users enter correct user:password pairs.

    4) No other user has sent a user:passwd pair with a newline at the
       end to the  proxy until now  (so we can  acctually describe the
       effect when it occurs the first time).

    The exploit:
    ~~~~~~~~~~~~
    1) Create a base64-encoded "user:passwd\n" string, f.e.:
       # echo "foo:bar" | mimencode
       # Zm9vOmJhcgo=

       Note that

        # echo -n "foo:bar" | mimencode

       (notice the  -n option!)  will strip  the trailing  newline and
       can't be used.   The newline at  the end is  essential for  the
       exploit,  since  most  external  authenticators will read _two_
       lines from the proxy and sent _two_ results back to the  proxy,
       shifting all subsquent  responses to authentication  request by
       one.

    2) telnet  to  your  proxy  and  sent  a valid but not  authorized
       request (lines marked with a * are your input lines):

        # telnet proxy 8080
        Trying 123.123.123.123
        Connected to proxy.home.net
        Escape character is '^]'
        * GET http://some.domain.net HTTP/1.0
        * Proxy-Authorization: Basic Zm9vOmJhcgo=
        *

       Please notice the  last extra newline  needed for the  Protocol
       (it has nothing to do with  the exploit, though).  An ACL  must
       match the given domain (here, some.domain.net), which uses  the
       external authentication program.

    3) You will see the response  for you user:passwd pair and due  to
       assumption 4),  this answer  is accurate.   Now, wait.   Once a
       different user sents his user:password pair -- which in turn is
       correct in general as stated  in assumption 3.) -- he  will get
       the  authentication  response  of  _your_  empty  line and most
       probably will be a  HTTP/1.0 407 Proxy Authentication  Required
       answer,  but  then,  the  user  will  try  again and... get the
       _correct_ answer of  his or her  _first_ try.   Now, the second
       answer (which most probably will be OK) is pending!

    4) Try to connect  again with another fake  user:password (without
       extra newline), most likely  using your favorite browser.   Now
       you should profit  from the pending  OK in step  3 and get  the
       page you want.  Please notice, that when caching is active, you
       can surf  as long  the name:password  pair is  available in the
       cache -- which can be quite long.

Solution

    Fixed in 2.3 branch.  Patch available at:

        http://squid.nlanr.net/Versions/v2/2.2/bugs/squid-2.2.stable5-newlines_in_auth.patch