Re: [squid-dev] [PATCH] Reuse reserved Negotiate and NTLM helpers after an idle timeout.
On 26/07/17 21:37, Christos Tsantilas wrote: Squid can be killed or maimed by enough clients that start multi-step connection authentication but never follow up with the second HTTP request while keeping their HTTP connection open. Affected helpers remain in the "reserved" state and cannot be reused for other clients. Observed helper exhaustion has happened without any malicious intent. To address the problem, we add a helper reservation timeout. Timed out reserved helpers may be reused by new clients/connections. To minimize problems with slow-to-resume-authentication clients, timed out reserved helpers are not reused until there are no unreserved running helpers left. The reservations are tracked using unique integer IDs. Also fixed Squid crashes caused by unexpected helper termination -- the raw UserRequest::authserver pointer could point to a deleted helper. This is a Measurement Factory project. Er, I see no attachment. Can you do this as a PR now? it will need someone to do that to get it committed nowdays. Amos ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] [RFC] Migrate explicit syslog calls to debugs
On 27/07/17 16:06, Alex Rousskov wrote: Hello, Squid master process uses many explicit syslog() calls like these: syslog(LOG_ALERT, "fork failed: %s", xstrerr(xerrno)); syslog(LOG_ALERT, "Suspiciously high workers value: %d", syslog(LOG_NOTICE, "Squid Parent: will start %d kids", (int)TheKids.count()); syslog(LOG_ALERT, "execvp failed: %s", xstrerr(xerrno)); syslog(LOG_NOTICE, "Squid Parent: %s process %d started", syslog(LOG_NOTICE, "Squid Parent: %s process %d exited with status %d", syslog(LOG_NOTICE, "Squid Parent: %s process %d exited due to signal %d with status %d", syslog(LOG_NOTICE, "Squid Parent: %s process %d exited", syslog(LOG_NOTICE, "Squid Parent: %s process %d will not" syslog(LOG_NOTICE, "Squid Parent: unknown child process %d exited", pid); syslog(LOG_ALERT, "Exiting due to unexpected forced shutdown"); syslog(LOG_ALERT, "Exiting due to repeated, frequent failures"); I propose to replace explicit syslog() calls with DBG_CRITICAL and DBG_IMPORTANT debugs() calls _and_ automatically enable syslog-logging of levels 0-1 debugs() calls made by the master process. The proposed combination should preserve the current syslog info while allowing us to use modern ostream-style formatting that is usually more convenient, often more powerful, and sometimes safer to use than printf-style formatting used by syslog(). It can easily result in log lines too long for syslog to record easily (IIRC some do brain-dead line wrapping at inconvenient lengths). So that will need to be accounted for in the design. The proposed approach would also make it easier to add master process debugging messages (that should not go to syslog by default). As Squid master process becomes smarter (e.g., an upcoming patch adds initial master reconfiguration support among other things), these debugging messages become desperately needed. What do you think? I wonder if the use of clog you suggested years ago to resolve the early startup messages problems should be fixed first. +1 on having this happen though, whenever it happens. Amos ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
[squid-dev] [RFC] Migrate explicit syslog calls to debugs
Hello, Squid master process uses many explicit syslog() calls like these: > syslog(LOG_ALERT, "fork failed: %s", xstrerr(xerrno)); > syslog(LOG_ALERT, "Suspiciously high workers value: %d", > syslog(LOG_NOTICE, "Squid Parent: will start %d kids", (int)TheKids.count()); > syslog(LOG_ALERT, "execvp failed: %s", xstrerr(xerrno)); > syslog(LOG_NOTICE, "Squid Parent: %s process %d started", > syslog(LOG_NOTICE, "Squid Parent: %s process %d exited with status %d", > syslog(LOG_NOTICE, "Squid Parent: %s process %d exited due to signal %d with > status %d", > syslog(LOG_NOTICE, "Squid Parent: %s process %d exited", > syslog(LOG_NOTICE, "Squid Parent: %s process %d will not" > syslog(LOG_NOTICE, "Squid Parent: unknown child process %d exited", pid); > syslog(LOG_ALERT, "Exiting due to unexpected forced shutdown"); > syslog(LOG_ALERT, "Exiting due to repeated, frequent failures"); I propose to replace explicit syslog() calls with DBG_CRITICAL and DBG_IMPORTANT debugs() calls _and_ automatically enable syslog-logging of levels 0-1 debugs() calls made by the master process. The proposed combination should preserve the current syslog info while allowing us to use modern ostream-style formatting that is usually more convenient, often more powerful, and sometimes safer to use than printf-style formatting used by syslog(). The proposed approach would also make it easier to add master process debugging messages (that should not go to syslog by default). As Squid master process becomes smarter (e.g., an upcoming patch adds initial master reconfiguration support among other things), these debugging messages become desperately needed. What do you think? Thank you, Alex. ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] Cache poisoning vulnerability 3.5.23
Hey Omid, It's not clear what do you mean by cache poisoning? There are couple options but there are missing technical pieces on how to re-produce the issue, what squid setup are you using ie squid.conf. How can I test it here on my test lab? Thanks, Eliezer Eliezer Croitoru Linux System Administrator Mobile: +972-5-28704261 Email: elie...@ngtech.co.il -Original Message- From: squid-dev [mailto:squid-dev-boun...@lists.squid-cache.org] On Behalf Of Omid Kosari Sent: Wednesday, July 26, 2017 13:19 To: squid-dev@lists.squid-cache.org Subject: [squid-dev] Cache poisoning vulnerability 3.5.23 Hello, Recently i have seen some Cache poisoning specially on android captive portal detection sites . My squid was 3.5.19 (from https://packages.debian.org/stretch/squid) on Ubuntu Linux 16.04 . Then i have upgraded to latest version 3.5.23 (from https://packages.debian.org/stretch/squid) and purged specific pages but again i can see cache poisoning on same pages . http://connectivitycheck.gstatic.com/generate_204 http://clients3.google.com/generate_204 http://172.217.20.206/generate_204 http://clients1.google.com/generate_204 http://google.com/generate_204 -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Cache-poisoning-vulnerability-3-5-23-tp4683214.html Sent from the Squid - Development mailing list archive at Nabble.com. ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
[squid-dev] Cache poisoning vulnerability 3.5.23
Hello, Recently i have seen some Cache poisoning specially on android captive portal detection sites . My squid was 3.5.19 (from https://packages.debian.org/stretch/squid) on Ubuntu Linux 16.04 . Then i have upgraded to latest version 3.5.23 (from https://packages.debian.org/stretch/squid) and purged specific pages but again i can see cache poisoning on same pages . http://connectivitycheck.gstatic.com/generate_204 http://clients3.google.com/generate_204 http://172.217.20.206/generate_204 http://clients1.google.com/generate_204 http://google.com/generate_204 -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Cache-poisoning-vulnerability-3-5-23-tp4683214.html Sent from the Squid - Development mailing list archive at Nabble.com. ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
[squid-dev] [PATCH] Reuse reserved Negotiate and NTLM helpers after an idle timeout.
Squid can be killed or maimed by enough clients that start multi-step connection authentication but never follow up with the second HTTP request while keeping their HTTP connection open. Affected helpers remain in the "reserved" state and cannot be reused for other clients. Observed helper exhaustion has happened without any malicious intent. To address the problem, we add a helper reservation timeout. Timed out reserved helpers may be reused by new clients/connections. To minimize problems with slow-to-resume-authentication clients, timed out reserved helpers are not reused until there are no unreserved running helpers left. The reservations are tracked using unique integer IDs. Also fixed Squid crashes caused by unexpected helper termination -- the raw UserRequest::authserver pointer could point to a deleted helper. This is a Measurement Factory project. ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
