TUCoPS :: Unix :: General :: squid2-2.htm

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