[PATCH] proxy.cgi: Mitigation for CVE-2025-62168 on squid

[PATCH] proxy.cgi: Mitigation for CVE-2025-62168 on squid

[Adolf Belka]

- The full fix for CVE-2025-62168 is in version squid-7.2
- However there are a lot of changes in squid from version 6 to 7 with all the error
   language files no longer provided directly, they have to be obtained from separate
   langauage packs now. Also several tools like cachmgr.cgi have been removed as the
   options can be obtained via different approaches.
- I have had a look at squid-7.2 and I believe I can do the upgrade but it will take some
   time to be sure it is working properly.
- In the interim, this patch adds the mitigation "email_err_data off" into squid.conf
   that is referenced in the CVE report.
- If someone else has already worked on squid-7.2 and has it ready to go now or soon,
   then this patch can be dropped.

Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
---
 html/cgi-bin/proxy.cgi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/html/cgi-bin/proxy.cgi b/html/cgi-bin/proxy.cgi
index fdb7c6a77..f0547e249 100644
--- a/html/cgi-bin/proxy.cgi
+++ b/html/cgi-bin/proxy.cgi
@@ -3109,6 +3109,7 @@ sub writeconfig
 shutdown_lifetime 5 seconds
 icp_port 0
 httpd_suppress_version_string on
+email_err_data off
 
 END
 	;
-- 
2.51.1.dirty

Re: [PATCH] proxy.cgi: Mitigation for CVE-2025-62168 on squid

[Matthias Fischer]

Hi,

On 20.10.2025 12:48, Adolf Belka wrote:
> - The full fix for CVE-2025-62168 is in version squid-7.2
> - However there are a lot of changes in squid from version 6 to 7 with all the error
>    language files no longer provided directly, they have to be obtained from separate
>    langauage packs now. Also several tools like cachmgr.cgi have been removed as the
>    options can be obtained via different approaches.
> - I have had a look at squid-7.2 and I believe I can do the upgrade but it will take some
>    time to be sure it is working properly.
> - In the interim, this patch adds the mitigation "email_err_data off" into squid.conf
>    that is referenced in the CVE report.
> - If someone else has already worked on squid-7.2 and has it ready to go now or soon,
>    then this patch can be dropped.

Yes, I did it - and I'm testing it with Core 197:

...
2025/10/20 19:52:50 kid1| Processing Configuration File:
/etc/squid/squid.conf (depth 0)
2025/10/20 19:52:50 kid1| Current Directory is /
2025/10/20 19:52:50 kid1| Starting Squid Cache version 7.2 for
x86_64-pc-linux-gnu...
...

But I don't really trust the new 'squid' yet. Building was simple - I
only changed version and checksum in the existing lfs-file, that's all
it needed. And a few changes in the rootfile - as Adolf wrote, several
tools have been removed. By the way: in the current v7.2, the "error
language files" are included, no need to download them seperately! So
upgrading was easy, but... ;-)

Right now, its running without seen problems. What bothers me, is that
the 'proxy.cgi' needs to be adjusted. This seems to be a bit tricky and
I won't have the time for this in the near future. Even if my original
'squid.conf' works fine I don't know what happens if someone needs the
removed "basic_smb_lm_auth and ntlm_smb_lm_auth helpers" (e.g. from
changelog) and clicks on "Save and restart"...

Other changes (v7.0.1):
	- Remove Edge Side Include (ESI) protocol
	- Remove Ident protocol support
	- Remove cache_object protocol support
	- Remove cachemgr.cgi tool
	- Remove tool 'purge' for management of UFS/AUFS/DiskD caches
	- Remove squidclient
And the list goes on...

A change in v7.2 ("Bug 5504: Document that Squid discards invalid
rewrite-url") made an acl necessary (url_rewrite_access deny CONNECT)
because 'squid.conf' was suddenly flooded with errors: "URL-rewrite
produces invalid request: CONNECT
http://[ROUTER_IP_DELETED]:81/images/urlfilter/1x1.gif HTTP/1.1 current
master transaction: master53"
And the v7.1 didn't ran at all, because of similar problems with the
urlfilter. Hm...
So I would recommend that we adjust the 'proxy'cgi' accordingly and test
very carefully, before we upgrade 'squid' to 7.2. I'll test and report...

Jm2c - Regards
Matthias
> Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
> ---
>  html/cgi-bin/proxy.cgi | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/html/cgi-bin/proxy.cgi b/html/cgi-bin/proxy.cgi
> index fdb7c6a77..f0547e249 100644
> --- a/html/cgi-bin/proxy.cgi
> +++ b/html/cgi-bin/proxy.cgi
> @@ -3109,6 +3109,7 @@ sub writeconfig
>  shutdown_lifetime 5 seconds
>  icp_port 0
>  httpd_suppress_version_string on
> +email_err_data off
>  
>  END
>  	;

Re: [PATCH] proxy.cgi: Mitigation for CVE-2025-62168 on squid

[Michael Tremer]

Thank you. I have merged this into Core Update 198.

> On 20 Oct 2025, at 11:48, Adolf Belka <adolf.belka@ipfire.org> wrote:
> 
> - The full fix for CVE-2025-62168 is in version squid-7.2
> - However there are a lot of changes in squid from version 6 to 7 with all the error
>   language files no longer provided directly, they have to be obtained from separate
>   langauage packs now. Also several tools like cachmgr.cgi have been removed as the
>   options can be obtained via different approaches.
> - I have had a look at squid-7.2 and I believe I can do the upgrade but it will take some
>   time to be sure it is working properly.
> - In the interim, this patch adds the mitigation "email_err_data off" into squid.conf
>   that is referenced in the CVE report.
> - If someone else has already worked on squid-7.2 and has it ready to go now or soon,
>   then this patch can be dropped.
> 
> Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
> ---
> html/cgi-bin/proxy.cgi | 1 +
> 1 file changed, 1 insertion(+)
> 
> diff --git a/html/cgi-bin/proxy.cgi b/html/cgi-bin/proxy.cgi
> index fdb7c6a77..f0547e249 100644
> --- a/html/cgi-bin/proxy.cgi
> +++ b/html/cgi-bin/proxy.cgi
> @@ -3109,6 +3109,7 @@ sub writeconfig
> shutdown_lifetime 5 seconds
> icp_port 0
> httpd_suppress_version_string on
> +email_err_data off
> 
> END
> ;
> -- 
> 2.51.1.dirty
> 
> 

Re: [PATCH] proxy.cgi: Mitigation for CVE-2025-62168 on squid

[Michael Tremer]

Hello Matthias,

Thanks for looking into this. It seems that we have a bit of work on our hands, but doesn’t sound too bad after all.

> On 20 Oct 2025, at 20:44, Matthias Fischer <matthias.fischer@ipfire.org> wrote:
> 
> Hi,
> 
> On 20.10.2025 12:48, Adolf Belka wrote:
>> - The full fix for CVE-2025-62168 is in version squid-7.2
>> - However there are a lot of changes in squid from version 6 to 7 with all the error
>>   language files no longer provided directly, they have to be obtained from separate
>>   langauage packs now. Also several tools like cachmgr.cgi have been removed as the
>>   options can be obtained via different approaches.
>> - I have had a look at squid-7.2 and I believe I can do the upgrade but it will take some
>>   time to be sure it is working properly.
>> - In the interim, this patch adds the mitigation "email_err_data off" into squid.conf
>>   that is referenced in the CVE report.
>> - If someone else has already worked on squid-7.2 and has it ready to go now or soon,
>>   then this patch can be dropped.
> 
> Yes, I did it - and I'm testing it with Core 197:
> 
> ...
> 2025/10/20 19:52:50 kid1| Processing Configuration File:
> /etc/squid/squid.conf (depth 0)
> 2025/10/20 19:52:50 kid1| Current Directory is /
> 2025/10/20 19:52:50 kid1| Starting Squid Cache version 7.2 for
> x86_64-pc-linux-gnu...
> ...
> 
> But I don't really trust the new 'squid' yet. Building was simple - I
> only changed version and checksum in the existing lfs-file, that's all
> it needed. And a few changes in the rootfile - as Adolf wrote, several
> tools have been removed. By the way: in the current v7.2, the "error
> language files" are included, no need to download them seperately! So
> upgrading was easy, but... ;-)
> 
> Right now, its running without seen problems. What bothers me, is that
> the 'proxy.cgi' needs to be adjusted. This seems to be a bit tricky and
> I won't have the time for this in the near future. Even if my original
> 'squid.conf' works fine I don't know what happens if someone needs the
> removed "basic_smb_lm_auth and ntlm_smb_lm_auth helpers" (e.g. from
> changelog) and clicks on "Save and restart"...
> 
> Other changes (v7.0.1):
> - Remove Edge Side Include (ESI) protocol
> - Remove Ident protocol support
> - Remove cache_object protocol support
> - Remove cachemgr.cgi tool
> - Remove tool 'purge' for management of UFS/AUFS/DiskD caches
> - Remove squidclient
> And the list goes on...

Let’s go through this one by one...

- Remove Edge Side Include (ESI) protocol

We don’t use this as far as I can see.

- Remove Ident protocol support

We have the option, but hopefully nobody is using this any more. We will have to remove it from the UI, mention it in the changelog and done.

- Remove cache_object protocol support

We should not be using this.

- Remove cachemgr.cgi tool

This is installed and linked on the web UI. We will have to remove this too.

- Remove tool 'purge' for management of UFS/AUFS/DiskD caches

This is installed, but we don’t call it.

- Remove squidclient

Installed, but also not used.

- Remove disabled classful networks code

I don’t know what this could possibly mean. I don’t think it is referring to parsing the ACLs, but if it does, we found find out about it very quickly.

- Remove dead Multicast Miss Stream feature
- Remove broken and disabled icpPktDump()
- Remove deprecated string memory pools API

Since these are all dead and broken, we should not worry about them at all.

> A change in v7.2 ("Bug 5504: Document that Squid discards invalid
> rewrite-url") made an acl necessary (url_rewrite_access deny CONNECT)
> because 'squid.conf' was suddenly flooded with errors: "URL-rewrite
> produces invalid request: CONNECT
> http://[ROUTER_IP_DELETED]:81/images/urlfilter/1x1.gif HTTP/1.1 current
> master transaction: master53"
> And the v7.1 didn't ran at all, because of similar problems with the
> urlfilter. Hm...

That is not good. But testing will tell us more about where this is going wrong.

> So I would recommend that we adjust the 'proxy'cgi' accordingly and test
> very carefully, before we upgrade 'squid' to 7.2. I'll test and report...

Would you like to create a branch and submit the changes one by one?

-Michael

> 
> Jm2c - Regards
> Matthias
>> Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
>> ---
>> html/cgi-bin/proxy.cgi | 1 +
>> 1 file changed, 1 insertion(+)
>> 
>> diff --git a/html/cgi-bin/proxy.cgi b/html/cgi-bin/proxy.cgi
>> index fdb7c6a77..f0547e249 100644
>> --- a/html/cgi-bin/proxy.cgi
>> +++ b/html/cgi-bin/proxy.cgi
>> @@ -3109,6 +3109,7 @@ sub writeconfig
>> shutdown_lifetime 5 seconds
>> icp_port 0
>> httpd_suppress_version_string on
>> +email_err_data off
>> 
>> END
>> ;
> 
> 

Re: [PATCH] proxy.cgi: Mitigation for CVE-2025-62168 on squid

[Matthias Fischer]

On 22.10.2025 12:10, Michael Tremer wrote:
> Hello Matthias,

Hi Michael,
> Thanks for looking into this. It seems that we have a bit of work on our hands, but doesn’t sound too bad after all.

As far as I can see by now, adjusting the UI could be sufficient. IMHO.
Since my last post, v7.2 is running without any problems or logged
errors. I even activated 'privoxy' for testing - which the old 'squid'
didn't really like - and got no problems.
See further comments below.
>> On 20 Oct 2025, at 20:44, Matthias Fischer <matthias.fischer@ipfire.org> wrote:
>> 
>> Hi,
>> 
>> On 20.10.2025 12:48, Adolf Belka wrote:
>>> - The full fix for CVE-2025-62168 is in version squid-7.2
>>> - However there are a lot of changes in squid from version 6 to 7 with all the error
>>>   language files no longer provided directly, they have to be obtained from separate
>>>   langauage packs now. Also several tools like cachmgr.cgi have been removed as the
>>>   options can be obtained via different approaches.
>>> - I have had a look at squid-7.2 and I believe I can do the upgrade but it will take some
>>>   time to be sure it is working properly.
>>> - In the interim, this patch adds the mitigation "email_err_data off" into squid.conf
>>>   that is referenced in the CVE report.
>>> - If someone else has already worked on squid-7.2 and has it ready to go now or soon,
>>>   then this patch can be dropped.
>> 
>> Yes, I did it - and I'm testing it with Core 197:
>> 
>> ...
>> 2025/10/20 19:52:50 kid1| Processing Configuration File:
>> /etc/squid/squid.conf (depth 0)
>> 2025/10/20 19:52:50 kid1| Current Directory is /
>> 2025/10/20 19:52:50 kid1| Starting Squid Cache version 7.2 for
>> x86_64-pc-linux-gnu...
>> ...
>> 
>> But I don't really trust the new 'squid' yet. Building was simple - I
>> only changed version and checksum in the existing lfs-file, that's all
>> it needed. And a few changes in the rootfile - as Adolf wrote, several
>> tools have been removed. By the way: in the current v7.2, the "error
>> language files" are included, no need to download them seperately! So
>> upgrading was easy, but... ;-)
>> 
>> Right now, its running without seen problems. What bothers me, is that
>> the 'proxy.cgi' needs to be adjusted. This seems to be a bit tricky and
>> I won't have the time for this in the near future. Even if my original
>> 'squid.conf' works fine I don't know what happens if someone needs the
>> removed "basic_smb_lm_auth and ntlm_smb_lm_auth helpers" (e.g. from
>> changelog) and clicks on "Save and restart"...
>> 
>> Other changes (v7.0.1):
>> - Remove Edge Side Include (ESI) protocol
>> - Remove Ident protocol support
>> - Remove cache_object protocol support
>> - Remove cachemgr.cgi tool
>> - Remove tool 'purge' for management of UFS/AUFS/DiskD caches
>> - Remove squidclient
>> And the list goes on...
> 
> Let’s go through this one by one...
> 
> - Remove Edge Side Include (ESI) protocol
> 
> We don’t use this as far as I can see.
> 
> - Remove Ident protocol support
> 
> We have the option, but hopefully nobody is using this any more. We will have to remove it from the UI, mention it in the changelog and done.

This is something I'm not so familiar with: how do we remove "ident
protocol support" from 'proxy.cgi'!? This CGI is...huge...to say the
least. ;-)

At a quick glance I find 137 lines of code containing "ident".

E.g., I find "my $identdir =", "my $identhosts =", various
$proxysettings. Can all these entries and lines be deleted?

For example, what has to be done with code blocks as starting at line 438:

...
if (!($proxysettings{'AUTH_METHOD'} eq 'none'))
{
	unless (($proxysettings{'AUTH_METHOD'} eq 'ident') &&
...

and 1704:
...
if (!($proxysettings{'AUTH_METHOD'} eq 'none')) { if
(!($proxysettings{'AUTH_METHOD'} eq 'ident')) { print <<END
...

There a rather long code blocks following these conditions and I'm not
sure which can be deleted and which must stay.>
> - Remove cache_object protocol support
> 
> We should not be using this.
> 
> - Remove cachemgr.cgi tool
> 
> This is installed and linked on the web UI. We will have to remove this too.

This could be easier...
> - Remove tool 'purge' for management of UFS/AUFS/DiskD caches
> 
> This is installed, but we don’t call it.

Same as above.

> - Remove squidclient
> 
> Installed, but also not used.
>
> - Remove disabled classful networks code
> 
> I don’t know what this could possibly mean. I don’t think it is referring to parsing the ACLs, but if it does, we found find out about it very quickly.
> 
> - Remove dead Multicast Miss Stream feature
> - Remove broken and disabled icpPktDump()
> - Remove deprecated string memory pools API
> 
> Since these are all dead and broken, we should not worry about them at all.
> 
>> A change in v7.2 ("Bug 5504: Document that Squid discards invalid
>> rewrite-url") made an acl necessary (url_rewrite_access deny CONNECT)
>> because 'squid.conf' was suddenly flooded with errors: "URL-rewrite
>> produces invalid request: CONNECT
>> http://[ROUTER_IP_DELETED]:81/images/urlfilter/1x1.gif HTTP/1.1 current
>> master transaction: master53"
>> And the v7.1 didn't ran at all, because of similar problems with the
>> urlfilter. Hm...
> 
> That is not good. But testing will tell us more about where this is going wrong.
> 
>> So I would recommend that we adjust the 'proxy'cgi' accordingly and test
>> very carefully, before we upgrade 'squid' to 7.2. I'll test and report...
> 
> Would you like to create a branch and submit the changes one by one?

I can try - but it will take a while. We will go on vacation for the
next two weeks and since my wife is unfortunately seriously ill, I don't
have as much time for projects like this as I used to. When were back,
I'll take a look and if in doubt, I will ask.

By the way - wouldn't it also make sense to remove the still contained
'clamav'-entries?

I'll see what I can do. ;-)

Best
Matthias
> -Michael
> 
>> 
>> Jm2c - Regards
>> Matthias
>>> Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
>>> ---
>>> html/cgi-bin/proxy.cgi | 1 +
>>> 1 file changed, 1 insertion(+)
>>> 
>>> diff --git a/html/cgi-bin/proxy.cgi b/html/cgi-bin/proxy.cgi
>>> index fdb7c6a77..f0547e249 100644
>>> --- a/html/cgi-bin/proxy.cgi
>>> +++ b/html/cgi-bin/proxy.cgi
>>> @@ -3109,6 +3109,7 @@ sub writeconfig
>>> shutdown_lifetime 5 seconds
>>> icp_port 0
>>> httpd_suppress_version_string on
>>> +email_err_data off
>>> 
>>> END
>>> ;
>> 
>> 
> 
> 

Re: [PATCH] proxy.cgi: Mitigation for CVE-2025-62168 on squid

[Adolf Belka]

Hi Matthias and Michael,

7.x is losing some bits but 8.x looks like it is going to be a complete other set of configuration.

Currently the config options that are still usable in 6.x, the vast majority are usable in 7.x, just some are removed.

However in 8.x it looks like none of the existing config options will be available.

https://www.squid-cache.org/Doc/config/

The above link shows all the config options and you will see that they are all crossed through. Select any that we currently use and you will see that it is removed in 8.x. For instance external_acl_type but also the basic acl and http_access.

If you click on the v8 link under Version specific guides you get a Forbidden, you don't have permission to access this resource message.

It seems like squid-8.x is going to be totally different to what is available now but there is no info about what is going to replace all those existing config options. I can imagine that would create a horrendous mess for us in updating from the old config system to the new one. I somehow doubt it will work retrospectively with the existing configs.


Re the cachemgr.cgi file see my comments below.


On 22/10/2025 15:28, Matthias Fischer wrote:
> On 22.10.2025 12:10, Michael Tremer wrote:
>> Hello Matthias,
> 
> Hi Michael,
>> Thanks for looking into this. It seems that we have a bit of work on our hands, but doesn’t sound too bad after all.
> 
> As far as I can see by now, adjusting the UI could be sufficient. IMHO.
> Since my last post, v7.2 is running without any problems or logged
> errors. I even activated 'privoxy' for testing - which the old 'squid'
> didn't really like - and got no problems.
> See further comments below.
>>> On 20 Oct 2025, at 20:44, Matthias Fischer <matthias.fischer@ipfire.org> wrote:
>>>
>>> Hi,
>>>
>>> On 20.10.2025 12:48, Adolf Belka wrote:
>>>> - The full fix for CVE-2025-62168 is in version squid-7.2
>>>> - However there are a lot of changes in squid from version 6 to 7 with all the error
>>>>    language files no longer provided directly, they have to be obtained from separate
>>>>    langauage packs now. Also several tools like cachmgr.cgi have been removed as the
>>>>    options can be obtained via different approaches.
>>>> - I have had a look at squid-7.2 and I believe I can do the upgrade but it will take some
>>>>    time to be sure it is working properly.
>>>> - In the interim, this patch adds the mitigation "email_err_data off" into squid.conf
>>>>    that is referenced in the CVE report.
>>>> - If someone else has already worked on squid-7.2 and has it ready to go now or soon,
>>>>    then this patch can be dropped.
>>>
>>> Yes, I did it - and I'm testing it with Core 197:
>>>
>>> ...
>>> 2025/10/20 19:52:50 kid1| Processing Configuration File:
>>> /etc/squid/squid.conf (depth 0)
>>> 2025/10/20 19:52:50 kid1| Current Directory is /
>>> 2025/10/20 19:52:50 kid1| Starting Squid Cache version 7.2 for
>>> x86_64-pc-linux-gnu...
>>> ...
>>>
>>> But I don't really trust the new 'squid' yet. Building was simple - I
>>> only changed version and checksum in the existing lfs-file, that's all
>>> it needed. And a few changes in the rootfile - as Adolf wrote, several
>>> tools have been removed. By the way: in the current v7.2, the "error
>>> language files" are included, no need to download them seperately! So
>>> upgrading was easy, but... ;-)
>>>
>>> Right now, its running without seen problems. What bothers me, is that
>>> the 'proxy.cgi' needs to be adjusted. This seems to be a bit tricky and
>>> I won't have the time for this in the near future. Even if my original
>>> 'squid.conf' works fine I don't know what happens if someone needs the
>>> removed "basic_smb_lm_auth and ntlm_smb_lm_auth helpers" (e.g. from
>>> changelog) and clicks on "Save and restart"...
>>>
>>> Other changes (v7.0.1):
>>> - Remove Edge Side Include (ESI) protocol
>>> - Remove Ident protocol support
>>> - Remove cache_object protocol support
>>> - Remove cachemgr.cgi tool
>>> - Remove tool 'purge' for management of UFS/AUFS/DiskD caches
>>> - Remove squidclient
>>> And the list goes on...
>>
>> Let’s go through this one by one...
>>
>> - Remove Edge Side Include (ESI) protocol
>>
>> We don’t use this as far as I can see.
>>
>> - Remove Ident protocol support
>>
>> We have the option, but hopefully nobody is using this any more. We will have to remove it from the UI, mention it in the changelog and done.
> 
> This is something I'm not so familiar with: how do we remove "ident
> protocol support" from 'proxy.cgi'!? This CGI is...huge...to say the
> least. ;-)
> 
> At a quick glance I find 137 lines of code containing "ident".
> 
> E.g., I find "my $identdir =", "my $identhosts =", various
> $proxysettings. Can all these entries and lines be deleted?
> 
> For example, what has to be done with code blocks as starting at line 438:
> 
> ...
> if (!($proxysettings{'AUTH_METHOD'} eq 'none'))
> {
> 	unless (($proxysettings{'AUTH_METHOD'} eq 'ident') &&
> ...
> 
> and 1704:
> ...
> if (!($proxysettings{'AUTH_METHOD'} eq 'none')) { if
> (!($proxysettings{'AUTH_METHOD'} eq 'ident')) { print <<END
> ...
> 
> There a rather long code blocks following these conditions and I'm not
> sure which can be deleted and which must stay.>
>> - Remove cache_object protocol support
>>
>> We should not be using this.
>>
>> - Remove cachemgr.cgi tool
>>
>> This is installed and linked on the web UI. We will have to remove this too.

The cachemgr.cgi file just gives an html page that links to the actual html data for each entry. squid have said that as the actual data pages are now fully html compliant, the cachemgr.cgi tool is no longer needed and you can just go directly to the url for the menu and then select the one you want to see the data for.

The major difference is that for each entry you will need to change the end of the url from menu to the name of the entry desired.

However it does work. In trying to make this work I found out what causes us to get an Access Denied message when you leave the visible_hostname entry on the WUI blank. In this case the IPFire squid.conf file ends up with the FQDN for the system.
This is then put through the asnbl helper and it comes back and says that the IP for the IPFire system is not associated with an ASN and so it blocks it and we get the Access Denied message.

I then put the fqdn into the allowed domains whitelist on the URL Filter page and now the asnbl test is bypassed.

I have added info on to the web proxy documentation to say that if the Deny Selectively Announced Networks option is enabled then the IPFire FQDN has to be added to the URL Filter whitelist for allowed domains.

Anyway, the link for the cachemgr info just has to be changed to go the url

http://<ip-fire-fqdn>:800/squid-internal-mgr/menu

and you will get a text page of all the options available. You have to then replace menu in the url with the entry you want to get data for.

To be honest, I am not sure of the benefit from most of the data available, and some entries are empty, at least with my system. So an option could be to also do as you suggest and remove the link completely.

Regards,

Adolf.
> 
> This could be easier...
>> - Remove tool 'purge' for management of UFS/AUFS/DiskD caches
>>
>> This is installed, but we don’t call it.
> 
> Same as above.
> 
>> - Remove squidclient
>>
>> Installed, but also not used.
>>
>> - Remove disabled classful networks code
>>
>> I don’t know what this could possibly mean. I don’t think it is referring to parsing the ACLs, but if it does, we found find out about it very quickly.
>>
>> - Remove dead Multicast Miss Stream feature
>> - Remove broken and disabled icpPktDump()
>> - Remove deprecated string memory pools API
>>
>> Since these are all dead and broken, we should not worry about them at all.
>>
>>> A change in v7.2 ("Bug 5504: Document that Squid discards invalid
>>> rewrite-url") made an acl necessary (url_rewrite_access deny CONNECT)
>>> because 'squid.conf' was suddenly flooded with errors: "URL-rewrite
>>> produces invalid request: CONNECT
>>> http://[ROUTER_IP_DELETED]:81/images/urlfilter/1x1.gif HTTP/1.1 current
>>> master transaction: master53"
>>> And the v7.1 didn't ran at all, because of similar problems with the
>>> urlfilter. Hm...
>>
>> That is not good. But testing will tell us more about where this is going wrong.
>>
>>> So I would recommend that we adjust the 'proxy'cgi' accordingly and test
>>> very carefully, before we upgrade 'squid' to 7.2. I'll test and report...
>>
>> Would you like to create a branch and submit the changes one by one?
> 
> I can try - but it will take a while. We will go on vacation for the
> next two weeks and since my wife is unfortunately seriously ill, I don't
> have as much time for projects like this as I used to. When were back,
> I'll take a look and if in doubt, I will ask.
> 
> By the way - wouldn't it also make sense to remove the still contained
> 'clamav'-entries?
> 
> I'll see what I can do. ;-)
> 
> Best
> Matthias
>> -Michael
>>
>>>
>>> Jm2c - Regards
>>> Matthias
>>>> Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
>>>> ---
>>>> html/cgi-bin/proxy.cgi | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/html/cgi-bin/proxy.cgi b/html/cgi-bin/proxy.cgi
>>>> index fdb7c6a77..f0547e249 100644
>>>> --- a/html/cgi-bin/proxy.cgi
>>>> +++ b/html/cgi-bin/proxy.cgi
>>>> @@ -3109,6 +3109,7 @@ sub writeconfig
>>>> shutdown_lifetime 5 seconds
>>>> icp_port 0
>>>> httpd_suppress_version_string on
>>>> +email_err_data off
>>>>
>>>> END
>>>> ;
>>>
>>>
>>
>>
> 
> 

Re: [PATCH] proxy.cgi: Mitigation for CVE-2025-62168 on squid

[Michael Tremer]

Hello,

> On 22 Oct 2025, at 14:28, Matthias Fischer <matthias.fischer@ipfire.org> wrote:
> 
> On 22.10.2025 12:10, Michael Tremer wrote:
>> Hello Matthias,
> 
> Hi Michael,
>> Thanks for looking into this. It seems that we have a bit of work on our hands, but doesn’t sound too bad after all.
> 
> As far as I can see by now, adjusting the UI could be sufficient. IMHO.
> Since my last post, v7.2 is running without any problems or logged
> errors. I even activated 'privoxy' for testing - which the old 'squid'
> didn't really like - and got no problems.
> See further comments below.

Oh wow, a trip down memory lane...

>>> On 20 Oct 2025, at 20:44, Matthias Fischer <matthias.fischer@ipfire.org> wrote:
>>> 
>>> Hi,
>>> 
>>> On 20.10.2025 12:48, Adolf Belka wrote:
>>>> - The full fix for CVE-2025-62168 is in version squid-7.2
>>>> - However there are a lot of changes in squid from version 6 to 7 with all the error
>>>>  language files no longer provided directly, they have to be obtained from separate
>>>>  langauage packs now. Also several tools like cachmgr.cgi have been removed as the
>>>>  options can be obtained via different approaches.
>>>> - I have had a look at squid-7.2 and I believe I can do the upgrade but it will take some
>>>>  time to be sure it is working properly.
>>>> - In the interim, this patch adds the mitigation "email_err_data off" into squid.conf
>>>>  that is referenced in the CVE report.
>>>> - If someone else has already worked on squid-7.2 and has it ready to go now or soon,
>>>>  then this patch can be dropped.
>>> 
>>> Yes, I did it - and I'm testing it with Core 197:
>>> 
>>> ...
>>> 2025/10/20 19:52:50 kid1| Processing Configuration File:
>>> /etc/squid/squid.conf (depth 0)
>>> 2025/10/20 19:52:50 kid1| Current Directory is /
>>> 2025/10/20 19:52:50 kid1| Starting Squid Cache version 7.2 for
>>> x86_64-pc-linux-gnu...
>>> ...
>>> 
>>> But I don't really trust the new 'squid' yet. Building was simple - I
>>> only changed version and checksum in the existing lfs-file, that's all
>>> it needed. And a few changes in the rootfile - as Adolf wrote, several
>>> tools have been removed. By the way: in the current v7.2, the "error
>>> language files" are included, no need to download them seperately! So
>>> upgrading was easy, but... ;-)
>>> 
>>> Right now, its running without seen problems. What bothers me, is that
>>> the 'proxy.cgi' needs to be adjusted. This seems to be a bit tricky and
>>> I won't have the time for this in the near future. Even if my original
>>> 'squid.conf' works fine I don't know what happens if someone needs the
>>> removed "basic_smb_lm_auth and ntlm_smb_lm_auth helpers" (e.g. from
>>> changelog) and clicks on "Save and restart"...
>>> 
>>> Other changes (v7.0.1):
>>> - Remove Edge Side Include (ESI) protocol
>>> - Remove Ident protocol support
>>> - Remove cache_object protocol support
>>> - Remove cachemgr.cgi tool
>>> - Remove tool 'purge' for management of UFS/AUFS/DiskD caches
>>> - Remove squidclient
>>> And the list goes on...
>> 
>> Let’s go through this one by one...
>> 
>> - Remove Edge Side Include (ESI) protocol
>> 
>> We don’t use this as far as I can see.
>> 
>> - Remove Ident protocol support
>> 
>> We have the option, but hopefully nobody is using this any more. We will have to remove it from the UI, mention it in the changelog and done.
> 
> This is something I'm not so familiar with: how do we remove "ident
> protocol support" from 'proxy.cgi'!? This CGI is...huge...to say the
> least. ;-)
> 
> At a quick glance I find 137 lines of code containing "ident".
> 
> E.g., I find "my $identdir =", "my $identhosts =", various
> $proxysettings. Can all these entries and lines be deleted?
> 
> For example, what has to be done with code blocks as starting at line 438:
> 
> ...
> if (!($proxysettings{'AUTH_METHOD'} eq 'none'))
> {
> unless (($proxysettings{'AUTH_METHOD'} eq 'ident') &&
> ...
> 
> and 1704:
> ...
> if (!($proxysettings{'AUTH_METHOD'} eq 'none')) { if
> (!($proxysettings{'AUTH_METHOD'} eq 'ident')) { print <<END
> ...
> 
> There a rather long code blocks following these conditions and I'm not
> sure which can be deleted and which must stay.>

No problem. Would Adolf like to have a look or pass it straight to me?

>> - Remove cache_object protocol support
>> 
>> We should not be using this.
>> 
>> - Remove cachemgr.cgi tool
>> 
>> This is installed and linked on the web UI. We will have to remove this too.
> 
> This could be easier...
>> - Remove tool 'purge' for management of UFS/AUFS/DiskD caches
>> 
>> This is installed, but we don’t call it.
> 
> Same as above.
> 
>> - Remove squidclient
>> 
>> Installed, but also not used.
>> 
>> - Remove disabled classful networks code
>> 
>> I don’t know what this could possibly mean. I don’t think it is referring to parsing the ACLs, but if it does, we found find out about it very quickly.
>> 
>> - Remove dead Multicast Miss Stream feature
>> - Remove broken and disabled icpPktDump()
>> - Remove deprecated string memory pools API
>> 
>> Since these are all dead and broken, we should not worry about them at all.
>> 
>>> A change in v7.2 ("Bug 5504: Document that Squid discards invalid
>>> rewrite-url") made an acl necessary (url_rewrite_access deny CONNECT)
>>> because 'squid.conf' was suddenly flooded with errors: "URL-rewrite
>>> produces invalid request: CONNECT
>>> http://[ROUTER_IP_DELETED]:81/images/urlfilter/1x1.gif HTTP/1.1 current
>>> master transaction: master53"
>>> And the v7.1 didn't ran at all, because of similar problems with the
>>> urlfilter. Hm...
>> 
>> That is not good. But testing will tell us more about where this is going wrong.
>> 
>>> So I would recommend that we adjust the 'proxy'cgi' accordingly and test
>>> very carefully, before we upgrade 'squid' to 7.2. I'll test and report...
>> 
>> Would you like to create a branch and submit the changes one by one?
> 
> I can try - but it will take a while. We will go on vacation for the
> next two weeks and since my wife is unfortunately seriously ill, I don't
> have as much time for projects like this as I used to. When were back,
> I'll take a look and if in doubt, I will ask.

Happy holidays and sorry to hear about your wife.

I would say it probably is best to use your time to help us test. You are very familiar with squid and running it in production, so applying any changes to your system and testing them there would be a good start.

> By the way - wouldn't it also make sense to remove the still contained
> 'clamav'-entries?

Yes, there would be a lot of stuff to be cleaned up in proxy.cgi, but who has the time for this?

Best,
-Michael

> I'll see what I can do. ;-)
> 
> Best
> Matthias
>> -Michael
>> 
>>> 
>>> Jm2c - Regards
>>> Matthias
>>>> Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
>>>> ---
>>>> html/cgi-bin/proxy.cgi | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>> 
>>>> diff --git a/html/cgi-bin/proxy.cgi b/html/cgi-bin/proxy.cgi
>>>> index fdb7c6a77..f0547e249 100644
>>>> --- a/html/cgi-bin/proxy.cgi
>>>> +++ b/html/cgi-bin/proxy.cgi
>>>> @@ -3109,6 +3109,7 @@ sub writeconfig
>>>> shutdown_lifetime 5 seconds
>>>> icp_port 0
>>>> httpd_suppress_version_string on
>>>> +email_err_data off
>>>> 
>>>> END
>>>> ;

Re: [PATCH] proxy.cgi: Mitigation for CVE-2025-62168 on squid

[Michael Tremer]

Hello everyone,

> On 22 Oct 2025, at 15:25, Adolf Belka <adolf.belka@ipfire.org> wrote:
> 
> Hi Matthias and Michael,
> 
> 7.x is losing some bits but 8.x looks like it is going to be a complete other set of configuration.
> 
> Currently the config options that are still usable in 6.x, the vast majority are usable in 7.x, just some are removed.
> 
> However in 8.x it looks like none of the existing config options will be available.
> 
> https://www.squid-cache.org/Doc/config/

I hope this is just and error. I tried to search for some roadmap that features squid 8 (or even version 7), but I could not find anything. So let’s hope this will not change.

  https://wiki.squid-cache.org/RoadMap/index
  https://wiki.squid-cache.org/RoadMap/FeatureRemoval

> The above link shows all the config options and you will see that they are all crossed through. Select any that we currently use and you will see that it is removed in 8.x. For instance external_acl_type but also the basic acl and http_access.
> 
> If you click on the v8 link under Version specific guides you get a Forbidden, you don't have permission to access this resource message.

I am getting the same message.

> It seems like squid-8.x is going to be totally different to what is available now but there is no info about what is going to replace all those existing config options. I can imagine that would create a horrendous mess for us in updating from the old config system to the new one. I somehow doubt it will work retrospectively with the existing configs.

If this is the case, we would probably have to think really hard whether we can keep the proxy at all.

It used to be a very integral part of IPFire, but nowadays I don’t think that there are too many large deployments any more. If squid makes such large changes for basically very little benefit (as far as I can see now), we would not have the developer time to keep up with it. I would also expect that after weeks of invested time, this will just run as it was running before. How would we justify spending the time?

> Re the cachemgr.cgi file see my comments below.
> 
> 
> On 22/10/2025 15:28, Matthias Fischer wrote:
>> On 22.10.2025 12:10, Michael Tremer wrote:
>>> Hello Matthias,
>> Hi Michael,
>>> Thanks for looking into this. It seems that we have a bit of work on our hands, but doesn’t sound too bad after all.
>> As far as I can see by now, adjusting the UI could be sufficient. IMHO.
>> Since my last post, v7.2 is running without any problems or logged
>> errors. I even activated 'privoxy' for testing - which the old 'squid'
>> didn't really like - and got no problems.
>> See further comments below.
>>>> On 20 Oct 2025, at 20:44, Matthias Fischer <matthias.fischer@ipfire.org> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> On 20.10.2025 12:48, Adolf Belka wrote:
>>>>> - The full fix for CVE-2025-62168 is in version squid-7.2
>>>>> - However there are a lot of changes in squid from version 6 to 7 with all the error
>>>>>   language files no longer provided directly, they have to be obtained from separate
>>>>>   langauage packs now. Also several tools like cachmgr.cgi have been removed as the
>>>>>   options can be obtained via different approaches.
>>>>> - I have had a look at squid-7.2 and I believe I can do the upgrade but it will take some
>>>>>   time to be sure it is working properly.
>>>>> - In the interim, this patch adds the mitigation "email_err_data off" into squid.conf
>>>>>   that is referenced in the CVE report.
>>>>> - If someone else has already worked on squid-7.2 and has it ready to go now or soon,
>>>>>   then this patch can be dropped.
>>>> 
>>>> Yes, I did it - and I'm testing it with Core 197:
>>>> 
>>>> ...
>>>> 2025/10/20 19:52:50 kid1| Processing Configuration File:
>>>> /etc/squid/squid.conf (depth 0)
>>>> 2025/10/20 19:52:50 kid1| Current Directory is /
>>>> 2025/10/20 19:52:50 kid1| Starting Squid Cache version 7.2 for
>>>> x86_64-pc-linux-gnu...
>>>> ...
>>>> 
>>>> But I don't really trust the new 'squid' yet. Building was simple - I
>>>> only changed version and checksum in the existing lfs-file, that's all
>>>> it needed. And a few changes in the rootfile - as Adolf wrote, several
>>>> tools have been removed. By the way: in the current v7.2, the "error
>>>> language files" are included, no need to download them seperately! So
>>>> upgrading was easy, but... ;-)
>>>> 
>>>> Right now, its running without seen problems. What bothers me, is that
>>>> the 'proxy.cgi' needs to be adjusted. This seems to be a bit tricky and
>>>> I won't have the time for this in the near future. Even if my original
>>>> 'squid.conf' works fine I don't know what happens if someone needs the
>>>> removed "basic_smb_lm_auth and ntlm_smb_lm_auth helpers" (e.g. from
>>>> changelog) and clicks on "Save and restart"...
>>>> 
>>>> Other changes (v7.0.1):
>>>> - Remove Edge Side Include (ESI) protocol
>>>> - Remove Ident protocol support
>>>> - Remove cache_object protocol support
>>>> - Remove cachemgr.cgi tool
>>>> - Remove tool 'purge' for management of UFS/AUFS/DiskD caches
>>>> - Remove squidclient
>>>> And the list goes on...
>>> 
>>> Let’s go through this one by one...
>>> 
>>> - Remove Edge Side Include (ESI) protocol
>>> 
>>> We don’t use this as far as I can see.
>>> 
>>> - Remove Ident protocol support
>>> 
>>> We have the option, but hopefully nobody is using this any more. We will have to remove it from the UI, mention it in the changelog and done.
>> This is something I'm not so familiar with: how do we remove "ident
>> protocol support" from 'proxy.cgi'!? This CGI is...huge...to say the
>> least. ;-)
>> At a quick glance I find 137 lines of code containing "ident".
>> E.g., I find "my $identdir =", "my $identhosts =", various
>> $proxysettings. Can all these entries and lines be deleted?
>> For example, what has to be done with code blocks as starting at line 438:
>> ...
>> if (!($proxysettings{'AUTH_METHOD'} eq 'none'))
>> {
>> unless (($proxysettings{'AUTH_METHOD'} eq 'ident') &&
>> ...
>> and 1704:
>> ...
>> if (!($proxysettings{'AUTH_METHOD'} eq 'none')) { if
>> (!($proxysettings{'AUTH_METHOD'} eq 'ident')) { print <<END
>> ...
>> There a rather long code blocks following these conditions and I'm not
>> sure which can be deleted and which must stay.>
>>> - Remove cache_object protocol support
>>> 
>>> We should not be using this.
>>> 
>>> - Remove cachemgr.cgi tool
>>> 
>>> This is installed and linked on the web UI. We will have to remove this too.
> 
> The cachemgr.cgi file just gives an html page that links to the actual html data for each entry. squid have said that as the actual data pages are now fully html compliant, the cachemgr.cgi tool is no longer needed and you can just go directly to the url for the menu and then select the one you want to see the data for.
> 
> The major difference is that for each entry you will need to change the end of the url from menu to the name of the entry desired.
> 
> However it does work. In trying to make this work I found out what causes us to get an Access Denied message when you leave the visible_hostname entry on the WUI blank. In this case the IPFire squid.conf file ends up with the FQDN for the system.
> This is then put through the asnbl helper and it comes back and says that the IP for the IPFire system is not associated with an ASN and so it blocks it and we get the Access Denied message.
> 
> I then put the fqdn into the allowed domains whitelist on the URL Filter page and now the asnbl test is bypassed.
> 
> I have added info on to the web proxy documentation to say that if the Deny Selectively Announced Networks option is enabled then the IPFire FQDN has to be added to the URL Filter whitelist for allowed domains.
> 
> Anyway, the link for the cachemgr info just has to be changed to go the url
> 
> http://<ip-fire-fqdn>:800/squid-internal-mgr/menu
> 
> and you will get a text page of all the options available. You have to then replace menu in the url with the entry you want to get data for.
> 
> To be honest, I am not sure of the benefit from most of the data available, and some entries are empty, at least with my system. So an option could be to also do as you suggest and remove the link completely.

I have never understood why people want to see this. It is not very helpful for someone running IPFire. Is it interesting for development? I don’t think so, because I never looked at it.

Therefore I would not be unhappy with the feature going.

> Regards,
> 
> Adolf.
>> This could be easier...
>>> - Remove tool 'purge' for management of UFS/AUFS/DiskD caches
>>> 
>>> This is installed, but we don’t call it.
>> Same as above.
>>> - Remove squidclient
>>> 
>>> Installed, but also not used.
>>> 
>>> - Remove disabled classful networks code
>>> 
>>> I don’t know what this could possibly mean. I don’t think it is referring to parsing the ACLs, but if it does, we found find out about it very quickly.
>>> 
>>> - Remove dead Multicast Miss Stream feature
>>> - Remove broken and disabled icpPktDump()
>>> - Remove deprecated string memory pools API
>>> 
>>> Since these are all dead and broken, we should not worry about them at all.
>>> 
>>>> A change in v7.2 ("Bug 5504: Document that Squid discards invalid
>>>> rewrite-url") made an acl necessary (url_rewrite_access deny CONNECT)
>>>> because 'squid.conf' was suddenly flooded with errors: "URL-rewrite
>>>> produces invalid request: CONNECT
>>>> http://[ROUTER_IP_DELETED]:81/images/urlfilter/1x1.gif HTTP/1.1 current
>>>> master transaction: master53"
>>>> And the v7.1 didn't ran at all, because of similar problems with the
>>>> urlfilter. Hm...
>>> 
>>> That is not good. But testing will tell us more about where this is going wrong.
>>> 
>>>> So I would recommend that we adjust the 'proxy'cgi' accordingly and test
>>>> very carefully, before we upgrade 'squid' to 7.2. I'll test and report...
>>> 
>>> Would you like to create a branch and submit the changes one by one?
>> I can try - but it will take a while. We will go on vacation for the
>> next two weeks and since my wife is unfortunately seriously ill, I don't
>> have as much time for projects like this as I used to. When were back,
>> I'll take a look and if in doubt, I will ask.
>> By the way - wouldn't it also make sense to remove the still contained
>> 'clamav'-entries?
>> I'll see what I can do. ;-)
>> Best
>> Matthias
>>> -Michael
>>> 
>>>> 
>>>> Jm2c - Regards
>>>> Matthias
>>>>> Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
>>>>> ---
>>>>> html/cgi-bin/proxy.cgi | 1 +
>>>>> 1 file changed, 1 insertion(+)
>>>>> 
>>>>> diff --git a/html/cgi-bin/proxy.cgi b/html/cgi-bin/proxy.cgi
>>>>> index fdb7c6a77..f0547e249 100644
>>>>> --- a/html/cgi-bin/proxy.cgi
>>>>> +++ b/html/cgi-bin/proxy.cgi
>>>>> @@ -3109,6 +3109,7 @@ sub writeconfig
>>>>> shutdown_lifetime 5 seconds
>>>>> icp_port 0
>>>>> httpd_suppress_version_string on
>>>>> +email_err_data off
>>>>> 
>>>>> END
>>>>> ;