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 <a...@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
