https://bz.apache.org/bugzilla/show_bug.cgi?id=69408
--- Comment #1 from Ruediger Pluem <rpl...@apache.org> --- (In reply to tsyamamoto from comment #0) > Hi Team, > > We plan to apply the following three fixes for the Apache 2.4 > vulnerabilities CVE-2024-38476/CVE-2024-39884/CVE-2024-40725. > However, it seems that some code might be missing fixes, and I am concerned > about the completeness of these patches for Apache 2.4. > > - https://svn.apache.org/viewvc?view=revision&revision=1918560 > - https://svn.apache.org/viewvc?view=revision&revision=1918839 > - https://svn.apache.org/viewvc?view=revision&revision=1919249 > > I have a few questions: > 1) The following fixes have been merged into the trunk. > However, the same fixes have not been applied to the Apache 2.4 branch. > Could you please let me know the reason why these fixes have not been > applied to the Apache 2.4 branch? > https://svn.apache.org/viewvc?view=revision&revision=1918823 This one was backported to 2.4.x as r1920981 > https://svn.apache.org/viewvc?view=revision&revision=1918815 This one is missing and should be backported. > > 2) In the trunk, mod_proxy_balancer.c has been modified to use > ap_set_content_type_ex in two places. > > https://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/ > mod_proxy_balancer.c?r1=1918814&r2=1918813&pathrev=1918814 > On the other hand, in the Apache 2.4 branch, only one place has been > modified to use ap_set_content_type_ex, > and the other place remains as ap_set_content_type. > > https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/proxy/ > mod_proxy_balancer.c?r1=1918839&r2=1918838&pathrev=1918839 > Is the remaining ap_set_content_type in the Apache 2.4 branch a mistake? It was not backported completely. > > 3) In mod_proxy_html.c in the trunk and the Apache 2.4 branch, both > ap_set_content_type_ex and ap_set_content_type exist. > > https://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/ > mod_proxy_html.c?view=markup#l1022 > > https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/filters/ > mod_proxy_html.c?view=markup#l965 > It sets "text/html;charset=<charsetname>" which is not treated as a > handler name. > Is the remaining ap_set_content_type a mistake? No, as the source of cenc could be user provided data. > > 4) In mod_cern_meta.c, the call to the ap_set_content_type method remains. > > https://svn.apache.org/viewvc/httpd/httpd/trunk/modules/metadata/ > mod_cern_meta.c?view=markup#l253 > > https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/metadata/ > mod_cern_meta.c?view=markup#l253 > Therefore, it seems that the behavior changes when httpd.conf and meta > files are configured as follows. > > httpd.conf > ------------ > LoadModule cern_meta_module "modules/mod_cern_meta.so" > <Directory "/opt/apache/htdocs"> > MetaFiles On > MetaDir .meta > MetaSuffix .meta > </Directory> > ------------ > > /opt/apache/htdocs/.meta/hello.jpg.meta > ------------ > Content-Type: XXXXX > ------------ > Note: XXXXX is an invalid value that is not a typical MIME type. > > However, this configuration seems to be an unexpected use that is not > documented. > > Is the reason for not fixing mod_cern_meta.c to prevent any arbitrary > handler from being executed > if such an unexpected meta file is created? Exactly. Hence it should remain with ap_set_content_type -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
