Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1017951 > unrolled thread

Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2 Andreas Schulz <andreas.schulz@tds.fujitsu.com> - 2020-07-14 14:10 +0200
    Bug#965012: add. information Andreas Schulz <andreas.schulz@tds.fujitsu.com> - 2020-07-14 14:30 +0200
    Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2 Markus Koschany <apo@debian.org> - 2020-07-27 00:20 +0200
      Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2 [TT#2398327] SerNet Support Kevin Ivory <support@SerNet.de> - 2020-08-03 17:10 +0200
    Bug#965012: new test with debug_options ALL,9 Markus Koschany <apo@debian.org> - 2020-08-04 15:10 +0200
    Bug#965012: new test with debug_options ALL,9 Markus Koschany <apo@debian.org> - 2020-08-13 18:20 +0200
    Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2 [TT#2398327] SerNet Support Kevin Ivory <support@SerNet.de> - 2020-08-18 13:40 +0200
      Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2 [TT#2398327] Markus Koschany <apo@debian.org> - 2020-08-18 21:50 +0200
        Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2 [TT#2398327] SerNet Support Kevin Ivory <support@SerNet.de> - 2020-08-28 12:00 +0200
          Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2 [TT#2398327] Markus Koschany <apo@debian.org> - 2020-08-28 15:10 +0200
            Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2 [TT#2398327] SerNet Support Oliver Seufer <support@SerNet.de> - 2020-09-04 10:10 +0200
              Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2 [TT#2398327] Markus Koschany <apo@debian.org> - 2020-09-04 15:20 +0200
                Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2 [TT#2398327] SerNet Support Kevin Ivory <support@SerNet.de> - 2020-09-25 11:30 +0200
    Bug#965012: new test with debug_options ALL,9 <j.stribrsky@email.cz> - 2020-09-02 11:40 +0200

#1017951 — Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2

Package: squid
Version: 3.5.23-5+deb9u2.1
Severity: important
File: /usr/sbin/squid

Dear Maintainer,

We installed the security update deb9u2 and learned that no more
http-access (with icap) was possible. No problem with https because
https is forwarded directly and with disabled icap feature http also no problem.

In access.log I found:
1594709099.638      0 x.x.x.x ICAP_ERR_OTHER/000 0 RESPMOD (http://www.google.de/) 127.0.0.1

After downgrade to deb9u1 everything worked fine again. I enabled debugging
(debug_options 93,3) and found some squid loglines:

essential ICAP service is down after an options fetch failure: icap://127.0.0.1:1344/virus_scan [down,!opt]
and
ServiceRep.cc(534) noteAdaptationAnswer: failed to fetch options [down,!opt,fail1]

With a tcpdump on lo interface I found a strange behaviour:
squid -> icap:
syn
syn ack
ack
rst

So squid is sending a rst package? I can provide the tracefile if desired.
Furthermore the cache.log of squid with content of debug_options as above
mentioned.

I checked applied patches and after some tests and rebuilds I found that without
patch CVE-2019-12523 it worked again. We have sev. stretch squids (with
and without parent squids) and all have the same problem. Quite unsure
why I can't find anything on mailing lists.

-- System Information:
Debian Release: 9.12
  APT prefers oldstable-updates
  APT policy: (990, 'oldstable-updates'), (990, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-12-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages squid depends on:
ii  adduser                  3.115
ii  libc6                    2.24-11+deb9u4
ii  libcap2                  1:2.25-1
ii  libcomerr2               1.43.4-2+deb9u1
ii  libdb5.3                 5.3.28-12+deb9u1
ii  libdbi-perl              1.636-1+b1
ii  libecap3                 1.0.1-3.2
ii  libexpat1                2.2.0-2+deb9u3
ii  libgcc1                  1:6.3.0-18+deb9u1
ii  libgssapi-krb5-2         1.15-1+deb9u1
ii  libkrb5-3                1.15-1+deb9u1
ii  libldap-2.4-2            2.4.44+dfsg-5+deb9u4
ii  libltdl7                 2.4.6-2
ii  libnetfilter-conntrack3  1.0.6-2
ii  libnettle6               3.3-1+b2
ii  libpam0g                 1.1.8-3.6
ii  libsasl2-2               2.1.27~101-g0780600+dfsg-3+deb9u1
ii  libstdc++6               6.3.0-18+deb9u1
ii  libxml2                  2.9.4+dfsg1-2.2+deb9u2
ii  logrotate                3.11.0-0.1
ii  lsb-base                 9.20161125
ii  netbase                  5.4
ii  squid-common             3.5.23-5+deb9u2

Versions of packages squid recommends:
ii  libcap2-bin  1:2.25-1

Versions of packages squid suggests:
pn  resolvconf   <none>
pn  smbclient    <none>
pn  squid-cgi    <none>
pn  squid-purge  <none>
ii  squidclient  3.5.23-5+deb9u2
pn  ufw          <none>
pn  winbindd     <none>

/etc/squid/squid.conf changed:
.snip.
logformat icap_squid-ext %ts.%03tu %6icap::tr %>a %icap::to/%03icap::Hs %icap::>st %icap::rm (%ru) %un %icap::<A
icap_log syslog:local6.info icap_squid-ext
icap_enable on
icap_preview_enable on
icap_preview_size 128
icap_send_client_ip on
icap_service_failure_limit -1
icap_service service_resp_clamav respmode_precache bypass=0 icap://127.0.0.1:1344/virus_scan
adaptation_service_chain service_resp_CHAIN service_resp_clamav
adaptation_access service_resp_CHAIN deny CONNECT
adaptation_access service_resp_CHAIN allow all
cache_peer ... parent 8080 0 no-query no-digest sourcehash name=srv-proxy
always_direct deny all
never_direct allow all
-- no debconf information


Kind regards,
Andreas Schulz

[toc] | [next] | [standalone]

#1017957 — Bug#965012: add. information

Hi,

there is a little mistake in reporting. I build a own package and forgot
to replace it with the original one before opening the report:

was:
Package: squid
Version: 3.5.23-5+deb9u2.1
Severity: important
File: /usr/sbin/squid

correct:
Package: squid
Version: 3.5.23-5+deb9u2
Severity: important
File: /usr/sbin/squid

regards,
Andreas

[toc] | [prev] | [next] | [standalone]

#1019412

[Multipart message — attachments visible in raw view] — view raw

Hello Andreas,

On Tue, 14 Jul 2020 13:57:48 +0200 Andreas Schulz
<andreas.schulz@tds.fujitsu.com> wrote:
> Package: squid
> Version: 3.5.23-5+deb9u2.1
> Severity: important
> File: /usr/sbin/squid
> 
> Dear Maintainer,
> 
> We installed the security update deb9u2 and learned that no more
> http-access (with icap) was possible.


I am not the maintainer but I have prepared the security update for
squid3 in Stretch. So far you are the only one who reported this
problem. I had sent a request for testing but never received any
feedback. [1] Please note that Stretch is now supported by the LTS team.
We have a dedicated mailing list where you can report problems dedicated
to packages in Stretch called debian-lts@lists.debian.org.

Could you set debug_options to ALL,9 (which should enable full debugging
according to the squid wiki) and reproduce the issue again? Please
attach the complete log either to this bug report or send it to me via
private email directly.

The patch for CVE-2019-12523 contains only one line that appears to
touch icap related code in src/adaptation/icap/ModXact.cc. I have
reverted this change and attached a new CVE-2019-12523.patch. Could you
apply it and report back if it makes any difference? Otherwise only the
debug log could help to narrow down the problem.

Regards,

Markus



[1] https://lists.debian.org/debian-lts/2020/07/msg00018.html

[toc] | [prev] | [next] | [standalone]

#1020394 — Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2 [TT#2398327]

Just for the sake of completeness: we have this problem as well
and still have many systems with Debian Stretch that need Squid Icap
to communicate with Avira Savapi antivirus. Because this bugs hits
us as well, we are now holding on to version 3.5.23-5+deb9u1.

On Mon, 27 Jul 2020 00:15:18 +0200 Markus Koschany <apo@debian.org> wrote:
> Hello Andreas,
> 
> On Tue, 14 Jul 2020 13:57:48 +0200 Andreas Schulz
> <andreas.schulz@tds.fujitsu.com> wrote:
> > Package: squid
> > Version: 3.5.23-5+deb9u2.1
> > Severity: important
> > File: /usr/sbin/squid
> > 
> > Dear Maintainer,
> > 
> > We installed the security update deb9u2 and learned that no more
> > http-access (with icap) was possible.
> 
> 
> I am not the maintainer but I have prepared the security update for
> squid3 in Stretch. So far you are the only one who reported this
> problem. I had sent a request for testing but never received any
> feedback. [1] Please note that Stretch is now supported by the LTS team.
> We have a dedicated mailing list where you can report problems dedicated
> to packages in Stretch called debian-lts@lists.debian.org.
> 
> Could you set debug_options to ALL,9 (which should enable full debugging
> according to the squid wiki) and reproduce the issue again? Please
> attach the complete log either to this bug report or send it to me via
> private email directly.
> 
> The patch for CVE-2019-12523 contains only one line that appears to
> touch icap related code in src/adaptation/icap/ModXact.cc. I have
> reverted this change and attached a new CVE-2019-12523.patch. Could you
> apply it and report back if it makes any difference? Otherwise only the
> debug log could help to narrow down the problem.
> 
> Regards,
> 
> Markus
> 
> 
> 
> [1] https://lists.debian.org/debian-lts/2020/07/msg00018.html

Best regards
Kevin Ivory (SerNet Support)
-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: 0551-370000-0, mailto:kontakt@sernet.de
Gesch.F.: Dr. Johannes Loxen und Reinhild Jung
AG Göttingen: HR-B 2816 - http://www.sernet.de

[toc] | [prev] | [next] | [standalone]

#1020517 — Bug#965012: new test with debug_options ALL,9

[Multipart message — attachments visible in raw view] — view raw

Hello Andreas,

thanks for your patience. I believe I have found the underlying problem.
It is a parsing issue in src/adaptation/icap/ModXact.cc and HttpMsg.cc.

2020/07/28 09:55:14.614 kid1| 58,3| HttpMsg.cc(184) parse:
HttpMsg::parse: cannot parse isolated headers in 'OPTIONS
icap://127.0.0.1:1344/virus_scan ICAP/1.0

To fix CVE-2019-12523 the urlParse function had to be updated to use the
new SBuf API for better access checks. However at one point in time
upstream did no longer used this function to parse icap headers and
simply copied an already known url. I have attached the
CVE-2019-12523.patch. You can just replace it with the old one. If
everything works as expected I will upload this change as +deb9u3 shortly.

Regards,

Markus

[toc] | [prev] | [next] | [standalone]

#1021482 — Bug#965012: new test with debug_options ALL,9

[Multipart message — attachments visible in raw view] — view raw

Hello Andreas,

Am 07.08.20 um 10:40 schrieb Andreas Schulz:
[...]
> now everything compiles but I still have ICAP-errors. Just to be sure
> that I did everything correctly:
> 
> - apt source squid3
> - quilt pop -a
> - replaced the package patch with yours
> - quilt push -a
> - built packages and installed them


You did nothing wrong but you could add a new changelog entry with a new
version number and then run dpkg-source -b to create a new source
package. After that you can easily compare the old source package with
the new one by running
	
	debdiff old.dsc new.dsc > my.debdiff

which highlights all the changes and also ensures the patch got applied
correctly.

In short, I have corrected the remaining error and I will upload a new
version today. The new package should be available on all mirrors within
24 hours.

For future reference:

The icap exception is triggered by two asserts (Must macros in squid
terminology) the one in src/adaptation/icap/OptXact.cc line 70 and
src/adaptation/icap/ModXact.cc line 1473. In order to fix CVE-2019-12523
the idea also was to better check for supported protocols. However the
urlParse function in 3.x and the corresponding AnyP::Uri::parse function
in 4.x are declared differently. While urlParse is of type HttpRequest,
AnyP::Uri::parse is of type boolean. The latter function simply returns
false if an invalid scheme is found but for the older urlParse function
NULL has to be returned. Since icap is not listed in urlParseProtocol
PROTO_NONE is returned which in turn triggers NULL. The corresponding
FindProtocolType function in 4.x would return PROTO_UNKNOWN instead and
only PROTO_NONE when the scheme is empty. I don't know why icap and ecap
are not explicitly defined as known protocols in 3.x and 4.x. In order
to keep the changes minimal I have simply added icap, icaps, ecap and
ecaps as known protocols now. Thanks to Nico Rogowski for pointing me in
the right direction.

The new update will also include an improved patch for CVE-2019-12529.


Regards,

Markus

[toc] | [prev] | [next] | [standalone]

#1021963 — Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2 [TT#2398327]

Hi Markus,

On Thu, 13 Aug 2020 21:56:14 +0200 Markus Koschany <apo@debian.org> wrote:
> Version: 3.5.23-5+deb9u3

thanks for the work on the patches. We have two different ICAP dependent
packages. After installing squid 3.5.23-5+deb9u3, ICAP worked for
Avira ICAP, but it did not work for our squid-redirector package for
BPjM index file.

The cache.log shows
2020/08/18 07:24:04 kid1| suspending ICAP service for too many failures
2020/08/18 07:24:04 kid1| essential ICAP service is suspended: icap://127.0.0.1:1344/service_scanner-reqmod [down,susp,fail11]

I guess its time for me to set up a test machine for debugging output.

Best reagrds
Kevin Ivory (SerNet Support)
-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: 0551-370000-0, mailto:kontakt@sernet.de
Gesch.F.: Dr. Johannes Loxen und Reinhild Jung
AG Göttingen: HR-B 2816 - http://www.sernet.de

[toc] | [prev] | [next] | [standalone]

#1022014 — Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2 [TT#2398327]

[Multipart message — attachments visible in raw view] — view raw

Hello Kevin,

On Tue, 18 Aug 2020 13:37:30 +0200 SerNet Support Kevin Ivory
<support@SerNet.de> wrote:
> Hi Markus,
> 
> On Thu, 13 Aug 2020 21:56:14 +0200 Markus Koschany <apo@debian.org> wrote:
> > Version: 3.5.23-5+deb9u3
> 
> thanks for the work on the patches. We have two different ICAP dependent
> packages. After installing squid 3.5.23-5+deb9u3, ICAP worked for
> Avira ICAP, but it did not work for our squid-redirector package for
> BPjM index file.
> 
> The cache.log shows
> 2020/08/18 07:24:04 kid1| suspending ICAP service for too many failures
> 2020/08/18 07:24:04 kid1| essential ICAP service is suspended: icap://127.0.0.1:1344/service_scanner-reqmod [down,susp,fail11]
> 
> I guess its time for me to set up a test machine for debugging output.

The default debug level shows not enough information to reproduce or
understand the problem. Please set debug_options to ALL,9 and send me
your cache.log and squid.conf file via private email.

Regards,

Markus

[toc] | [prev] | [next] | [standalone]

#1022985 — Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2 [TT#2398327]

Hello Markus,

we are having problems extracting a test case with debug data.
The problem arises sporadically on our customer systems with
HTTP POST or PUT, rarely with GET, sometimes with out HTTP
monitoring, sometimes with Debian updates.
Since I haven't been able to create a test case on our debug
vm system, I have created a debug file on a customer system.
Since the POST data might be critical to the customer,
is there any way to extract only the data you need?

All cases in my debug log (46 GB) seem to be of a POST
that is logged in access.log as
2020-08-27 11:29:24   1243 172.16.100.3 TAG_NONE/500 3640 POST http://srv1.first-businesspost.com/viper? - HIER_NONE/- text/html
The debug cache.log does contain SenderID= and Secret=

Am 18.08.20 um 21:38 schrieb Markus Koschany:
> On Tue, 18 Aug 2020 13:37:30 +0200 SerNet Support Kevin Ivory
> <support@SerNet.de> wrote:
>> Hi Markus,
>>
>> On Thu, 13 Aug 2020 21:56:14 +0200 Markus Koschany <apo@debian.org> wrote:
>>> Version: 3.5.23-5+deb9u3
>>
>> thanks for the work on the patches. We have two different ICAP dependent
>> packages. After installing squid 3.5.23-5+deb9u3, ICAP worked for
>> Avira ICAP, but it did not work for our squid-redirector package for
>> BPjM index file.
>>
>> The cache.log shows
>> 2020/08/18 07:24:04 kid1| suspending ICAP service for too many failures
>> 2020/08/18 07:24:04 kid1| essential ICAP service is suspended: icap://127.0.0.1:1344/service_scanner-reqmod [down,susp,fail11]
>>
>> I guess its time for me to set up a test machine for debugging output.
> 
> The default debug level shows not enough information to reproduce or
> understand the problem. Please set debug_options to ALL,9 and send me
> your cache.log and squid.conf file via private email.


Regards
Kevin Ivory (SerNet Support)
-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: 0551-370000-0, mailto:kontakt@sernet.de
Gesch.F.: Dr. Johannes Loxen und Reinhild Jung
AG Göttingen: HR-B 2816 - http://www.sernet.de

[toc] | [prev] | [next] | [standalone]

#1023006 — Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2 [TT#2398327]

[Multipart message — attachments visible in raw view] — view raw

Hello Kevin,

Am 28.08.20 um 11:53 schrieb SerNet Support Kevin Ivory:
[...]
> is there any way to extract only the data you need?
> 
> All cases in my debug log (46 GB) seem to be of a POST
> that is logged in access.log as
> 2020-08-27 11:29:24   1243 172.16.100.3 TAG_NONE/500 3640 POST
> http://srv1.first-businesspost.com/viper? - HIER_NONE/- text/html
> The debug cache.log does contain SenderID= and Secret=
[...]
>>> The cache.log shows
>>> 2020/08/18 07:24:04 kid1| suspending ICAP service for too many failures
>>> 2020/08/18 07:24:04 kid1| essential ICAP service is suspended:
>>> icap://127.0.0.1:1344/service_scanner-reqmod [down,susp,fail11]

In order to debug the problem I need to understand how the failing ICAP
service is related to your POST messages with internal server error 500.
With debug_options ALL,9 there should be a line with error: or Error:
before the ICAP service is suspended or something else that causes the
ICAP service to fail.

Some internet search also suggests that TAG_NONE/500 errors could be
completely unrelated to ICAP and indicate different issues like firewall
problems etc.

I would clone the customer's squid configuration and try to reproduce
the bug on your debug vm or try to find out what all those 500 errors
have in common.

Just to make sure that we are looking in the right direction, when you
unapply CVE-2019-12523.patch now, is everything working normal again?
I'm asking because there was another bug in CVE-2019-12529.patch that
prevented in some cases the authentication of clients when the kerberos
option was turned on. Rebuilding the squid package without those patches
may help to narrow down the problem.

Regards,

Markus

[toc] | [prev] | [next] | [standalone]

#1023745 — Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2 [TT#2398327]

Hello Markus,

This is Oliver. I just did some more troubleshooting and I found the error
message in the debug logfile:
kid1| 23,3| url.cc(471) urlParse: urlParse: Split URL 'http://:0' into proto='http', host='', port='0', path='/'
kid1| 23,3| url.cc(492) urlParse: urlParse: Invalid port '0'
kid1| 24,8| SBuf.cc(124) ~SBuf: SBuf20027193 destructed
kid1| 24,8| SBuf.cc(124) ~SBuf: SBuf20027192 destructed
kid1| 24,9| MemBlob.cc(83) ~MemBlob: destructed, this=0x55cc75a777f0 id=blob4598186 capacity=40 size=10
kid1| 55,7| HttpHeader.cc(480) clean: cleaning hdr: 0x55cc6735df38 owner: 2
kid1| 24,8| SBuf.cc(79) SBuf: SBuf20027202 created
kid1| 24,7| SBuf.cc(139) assign: assigning SBuf20027188 from SBuf20027202
kid1| 24,8| SBuf.cc(124) ~SBuf: SBuf20027202 destructed
kid1| 58,3| HttpMsg.cc(184) parse: HttpMsg::parse: cannot parse isolated headers in 'POST http://:0 HTTP/1.1
kid1| 0,3| TextException.cc(87) Throw: ModXact.cc:1083: exception: parsed || !error
kid1| 93,3| ../../../src/base/AsyncJobCalls.h(177) dial: Adaptation::Icap::Xaction::noteCommRead threw exception: parsed || !error
kid1| 45,9| cbdata.cc(492) cbdataReferenceValid: 0x55cc6d560d98
kid1| 11,5| HttpRequest.cc(466) detailError: current error details: 35/396407275
kid1| 93,3| Xaction.cc(512) setOutcome: Warning: reseting outcome: from ICAP_MOD to ICAP_ERR_OTHER
kid1| 93,4| ServiceRep.cc(80) noteFailure:  failure 1 out of 10 allowed in 0sec [up,fail1]

So somehow everything after http:// is broken on this post request.

Best regards,

Oliver


On Fri, 28 Aug 2020, Markus Koschany wrote:

> Hello Kevin,
> 
> Am 28.08.20 um 11:53 schrieb SerNet Support Kevin Ivory:
> [...]
> > is there any way to extract only the data you need?
> > 
> > All cases in my debug log (46 GB) seem to be of a POST
> > that is logged in access.log as
> > 2020-08-27 11:29:24   1243 172.16.100.3 TAG_NONE/500 3640 POST
> > http://srv1.first-businesspost.com/viper? - HIER_NONE/- text/html
> > The debug cache.log does contain SenderID= and Secret=
> [...]
> >>> The cache.log shows
> >>> 2020/08/18 07:24:04 kid1| suspending ICAP service for too many failures
> >>> 2020/08/18 07:24:04 kid1| essential ICAP service is suspended:
> >>> icap://127.0.0.1:1344/service_scanner-reqmod [down,susp,fail11]
> 
> In order to debug the problem I need to understand how the failing ICAP
> service is related to your POST messages with internal server error 500.
> With debug_options ALL,9 there should be a line with error: or Error:
> before the ICAP service is suspended or something else that causes the
> ICAP service to fail.
> 
> Some internet search also suggests that TAG_NONE/500 errors could be
> completely unrelated to ICAP and indicate different issues like firewall
> problems etc.
> 
> I would clone the customer's squid configuration and try to reproduce
> the bug on your debug vm or try to find out what all those 500 errors
> have in common.
> 
> Just to make sure that we are looking in the right direction, when you
> unapply CVE-2019-12523.patch now, is everything working normal again?
> I'm asking because there was another bug in CVE-2019-12529.patch that
> prevented in some cases the authentication of clients when the kerberos
> option was turned on. Rebuilding the squid package without those patches
> may help to narrow down the problem.
> 
> Regards,
> 
> Markus

[toc] | [prev] | [next] | [standalone]

#1023771 — Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2 [TT#2398327]

[Multipart message — attachments visible in raw view] — view raw

Hello Oliver,

Am 04.09.20 um 09:44 schrieb SerNet Support Oliver Seufer:
> Hello Markus,
> 
> This is Oliver. I just did some more troubleshooting and I found the error
> message in the debug logfile:
> kid1| 23,3| url.cc(471) urlParse: urlParse: Split URL 'http://:0' into proto='http', host='', port='0', path='/'
> kid1| 23,3| url.cc(492) urlParse: urlParse: Invalid port '0'

[...]

So my initial thought is that squid works correctly in this case. This
is the header which squid needs to parse.


ICAP/1.0 200 OK
ISTag: "10017;4140202;836248;8189206"
Server: AVIRA ICAP (1.21.1.61)
X-Response-Info: Clean
Encapsulated: req-hdr=0, null-body=215

HEAD http://:0 HTTP/1.0

User-Agent: w3m/0.5.3+git20170102
Accept: text/html, text/*;q=0.5, image/*, application/*, message/*
Accept-Language: en;q=1.0
Host: www.sernet.de
Accept-Encoding: gzip,bzip2,deflate

The

HEAD http://:0 HTTP/1.0

is weird. It starts with the http protocol but there is no domain name
and port 0 obviously does not exist. This probably used to work because
the squid3 parser was less strict before. I would try to change the
output of your AVIRA server. Is there a reason why it has to send this
specific HEAD line in the first place and can you modify it?

Regards,

Markus

[toc] | [prev] | [next] | [standalone]

#1026367 — Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2 [TT#2398327]

Hi Markus,

Oliver had submitted a bug report to Avira OEM integration support and
they have finally analyzed the problem. The developer states that it is
a problem of the (Debian or Mint) Squid build that does not occur in a
vanilla build of the standard squid3 package. German message below.

I will try a translation here:

"after analyzing the situation, our development confirms this behavior
with Linux Mint squid version 3.527 as well.
To all appearances, the squid server answers the request with "http://:0"
URL so that ICAP answers the same.

Excerpt of cache.log: (see below)
...

Our developer then compiled a stock Squid version 3.5.27 with similar
compiler flags as the default squid. This version did not reply with
" http://:0" URL.
We cannot decide if this problem occurs if it is a problem with the
squid build or a random error."

### end of my translation

Here the original statement in German language:

##- Please type your reply above this line -##

Your request (303525) been updated. To add additional comments, reply to this email.

Gerhard Boscher (Avira OEM Integration Support)

Sep 25, 2020, 10:44 GMT+2
Hallo Herr Ivory,

nach Untersuchung der Situation stellte unsere Entwicklung bpsw. ebenso mit der default Version von Squid unter Linux Mint  - 3.527. ein gleiches Verhalten fest.
Allen Anschein nach sendet bereits der Squid Server die "http://:0" URLs auf einen Request, so dass ICAP diese in seiner Antwort ebenfalls wiedergibt.

Auszug aus der cache.log:

2020/09/07 14:14:22.182 kid1| 93,9| ModXact.cc(198) handleCommConnected: will write [FD 12r;rw(1)G/R job9]:
REQMOD icap://127.0.0.1:1344/service_scanner-reqmod ICAP/1.0
Host: 127.0.0.1:1344
Date: Mon, 07 Sep 2020 12:14:22 GMT
Encapsulated: req-hdr=0, null-body=233
Allow: 204
HEAD http://:0 HTTP/1.0
User-Agent: w3m/0.5.3+git20170102
Accept: text/html, text/*;q=0.5, image/*, application/*, message/*
Accept-Encoding: gzip, compress, bzip, bzip2, deflate
Accept-Language: en;q=1.0
Host: www.sernet.de


Nachdem unser Entwickler eine Squid  Version 3.5.27 selbst kompilierte , dabei ähnliche Flags verwendete wie die beim system default squid, arbeitete diese Version ohne dass die "http://:0" URL auftrat.
Wir können abschließend leider nicht sagen ob dies eine Problematik des Squid Servers ist die bei system-default builds auftritt oder evtl. zufällig.

Mit freundlichen Grüßen / Best regards

Gerhard Boscher
Specialist OEM Integration Support Engineer




Am 04.09.20 um 15:09 schrieb Markus Koschany:
> Hello Oliver,
> 
> Am 04.09.20 um 09:44 schrieb SerNet Support Oliver Seufer:
>> Hello Markus,
>>
>> This is Oliver. I just did some more troubleshooting and I found the error
>> message in the debug logfile:
>> kid1| 23,3| url.cc(471) urlParse: urlParse: Split URL 'http://:0' into proto='http', host='', port='0', path='/'
>> kid1| 23,3| url.cc(492) urlParse: urlParse: Invalid port '0'
> 
> [...]
> 
> So my initial thought is that squid works correctly in this case. This
> is the header which squid needs to parse.
> 
> 
> ICAP/1.0 200 OK
> ISTag: "10017;4140202;836248;8189206"
> Server: AVIRA ICAP (1.21.1.61)
> X-Response-Info: Clean
> Encapsulated: req-hdr=0, null-body=215
> 
> HEAD http://:0 HTTP/1.0
> 
> User-Agent: w3m/0.5.3+git20170102
> Accept: text/html, text/*;q=0.5, image/*, application/*, message/*
> Accept-Language: en;q=1.0
> Host: www.sernet.de
> Accept-Encoding: gzip,bzip2,deflate
> 
> The
> 
> HEAD http://:0 HTTP/1.0
> 
> is weird. It starts with the http protocol but there is no domain name
> and port 0 obviously does not exist. This probably used to work because
> the squid3 parser was less strict before. I would try to change the
> output of your AVIRA server. Is there a reason why it has to send this
> specific HEAD line in the first place and can you modify it?


Best regards
Kevin Ivory (SerNet Support)
-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: 0551-370000-0, mailto:kontakt@sernet.de
Gesch.F.: Dr. Johannes Loxen und Reinhild Jung
AG Göttingen: HR-B 2816 - http://www.sernet.de

[toc] | [prev] | [next] | [standalone]

#1023508 — Bug#965012: new test with debug_options ALL,9

[Multipart message — attachments visible in raw view] — view raw

Hello Markus,

 
 
thanx for your fix, it helped us lot. But we have met another problem with 
this patch. Using version 3.5.23-5+deb9u1, in logs of ICAP server (in this 
case Eset GW Security) we do see, which file/URL was scanned, which we need 
to for further analysis in SIEM etc.

 
 
Sep  2 09:27:44 czsrv-jerproxy02 esets_daemon[28218]: summ[6e3a0106]: vdb=
46656, agent=icap, name="http://ocsp.digicert.com/", virus="is OK", action="
", info="", avstatus="clean", hop="accepted"

Sep  2 09:27:44 czsrv-jerproxy02 esets_icap[28243]: summ[6e530201]: method=
"REQMOD", object="http://ocsp.digicert.com/", status="clean", action=
"accepted"

Sep  2 09:27:44 czsrv-jerproxy02 esets_daemon[28218]: debug[6e3a0207]: Agent
icap accepted

Sep  2 09:27:44 czsrv-jerproxy02 esets_daemon[28218]: debug[6e3a0207]: 
Searching for section icap in configuration

Sep  2 09:27:44 czsrv-jerproxy02 esets_daemon[28218]: debug[6e3a0207]: Using
configuration for section icap

Sep  2 09:27:44 czsrv-jerproxy02 esets_daemon[28218]: summ[6e3a0207]: vdb=
46656, agent=icap, name="http://ocsp.digicert.com/", virus="is OK", action="
", info="", avstatus="clean", hop="accepted"

Sep  2 09:27:44 czsrv-jerproxy02 esets_icap[28243]: summ[6e530201]: method=
"RESPMOD", object="http://ocsp.digicert.com/", status="clean", action=
"accepted"

 
 
But using new version 3.5.23-5+deb9u3, instead of correct URL, there is 
http://:0 URL in request:

Sep  2 09:29:04 czsrv-jerproxy02 esets_daemon[28218]: debug[6e3a0108]: Agent
icap accepted

Sep  2 09:29:04 czsrv-jerproxy02 esets_daemon[28218]: debug[6e3a0108]: 
Searching for section icap in configuration

Sep  2 09:29:04 czsrv-jerproxy02 esets_daemon[28218]: debug[6e3a0108]: Using
configuration for section icap

Sep  2 09:29:04 czsrv-jerproxy02 esets_daemon[28218]: summ[6e3a0108]: vdb=
46656, agent=icap, name="http://:0", virus="is OK", action="", info="", 
avstatus="clean", hop="accepted"

Sep  2 09:29:04 czsrv-jerproxy02 esets_icap[28243]: summ[6e530101]: method=
"REQMOD", object="http://:0", status="clean", action="accepted"

Sep  2 09:29:04 czsrv-jerproxy02 esets_daemon[28218]: debug[6e3a0209]: Agent
icap accepted

Sep  2 09:29:04 czsrv-jerproxy02 esets_daemon[28218]: debug[6e3a0209]: 
Searching for section icap in configuration

Sep  2 09:29:04 czsrv-jerproxy02 esets_daemon[28218]: debug[6e3a0209]: Using
configuration for section icap

Sep  2 09:29:04 czsrv-jerproxy02 esets_daemon[28218]: summ[6e3a0209]: vdb=
46656, agent=icap, name="http://:0", virus="is OK", action="", info="", 
avstatus="clean", hop="accepted"

Sep  2 09:29:04 czsrv-jerproxy02 esets_icap[28243]: summ[6e530101]: method=
"RESPMOD", object="http://:0", status="clean", action="accepted"

 
 
I know, that from functional standpoint this is not critical, but from 
governance view, we are not able now prove, what was scanned and what was 
not. I know, that with SSL communication it is even worse, but still we are 
required to have these logs. Can you / anyone take a look onto it? 

 
 
               Thanx, best regards

                              Jarda Stribrsky

 
 
On Tue, 4 Aug 2020 15:01:08 +0200 Markus Koschany <apo@debian.org> wrote: 

> Hello Andreas, 

> 

> thanks for your patience. I believe I have found the underlying problem. 

> It is a parsing issue in src/adaptation/icap/ModXact.cc and HttpMsg.cc. 

> 

> 2020/07/28 09:55:14.614 kid1| 58,3| HttpMsg.cc(184) parse: 

> HttpMsg::parse: cannot parse isolated headers in 'OPTIONS 

> icap://127.0.0.1:1344/virus_scan ICAP/1.0 

> 

> To fix CVE-2019-12523 the urlParse function had to be updated to use the 

> new SBuf API for better access checks. However at one point in time 

> upstream did no longer used this function to parse icap headers and 

> simply copied an already known url. I have attached the 

> CVE-2019-12523.patch. You can just replace it with the old one. If 

> everything works as expected I will upload this change as +deb9u3 shortly.


> 

> Regards, 

> 

> Markus 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web