https://bz.apache.org/bugzilla/show_bug.cgi?id=69408
Bug ID: 69408
Summary: Modules Not Using ap_set_content_type_ex in Apache 2.4
Product: Apache httpd-2
Version: 2.4.62
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: All
Assignee: bugs@httpd.apache.org
Reporter: tsyamam...@fujitsu.com
Target Milestone: ---
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
https://svn.apache.org/viewvc?view=revision&revision=1918815
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?
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?
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?
--
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
