Re: [squid-users] ICAP problem in 3.1.18

On 4/01/2012 4:01 a.m., Daniel Beschorner wrote:
> One month ago I reported an ICAP regression in 3.1.17/18.
>
> In meantime I tracked down the problem to patch 10403 (Bug 2619).
> Maybe it helps to find the issue.
>
> Thank you
> Daniel
>
> --------
> After upgrading to 3.1.18 (+adaption compile patch) the following url =
> never stops loading in the browser
>
> http://x.ligatus.com/cgi-bin/ivw/CP/11260-365/83-1056/129647-107545-_129709=
> -105679-_128565-101085-//
>
> If I bypass the ICAP server for this url (which is indeed a redirect to =
> http://x.ligatus.com/blank.gif) all works fine.

No. That is a redirect to the URL "/blank.gif" and URL with no domain
and no protocol scheme. In HTTP that is an invalid Location: header,
which requires an absolute URL. This could be screwing up an ICAP server
which expects valid HTTP.

Your UA is assuming that it is a redirect to the same domain as the
original request. It could as easily be a redirect to
http://www.ivwbox.de/blank.gif which is the security domain the P3P
header says the reponse is part of. This is a XSS vulnerability.

Besides the invalid Location: header the 302 is cacheable and requires
revalidation. However performing that revalidation produces an invalid
status code of some type according to redbot.org. I was not able to
replicate the invalid status to see what it it is complaining about. But
if that revalidation failure happens through Squid the ICAP coudl be
breaking on that.

There is also a strange 1-byte body attached. It could be the body
pipeline or network I/O functions hung waiting for more data in order to
prevent single-byte packets.

Amos
Received on Wed Jan 04 2012 - 07:05:00 MST