https://bz.apache.org/bugzilla/show_bug.cgi?id=65616
--- Comment #4 from Yann Ylavic <ylavic....@gmail.com> --- (In reply to Sylvain Beucler from comment #3) > > > CVE-2021-36160 is actually fixed by r1892874 > > I'm confused, as far as I understand: > - CVE-2021-36160 is fixed by r1892805 (mod_proxy_uwsgi) > r1892805 was shipped as a fix for CVE-2021-36160 in Debian, Ubuntu and > SuSE, > in Apache HTTPD itself, and in prior stand-alone module from unbit uwsgi > - r1892874 fixes CVE-2021-40438 (mod_proxy) > (+ 3 follow-up commits) Sorry if I wasn't clear, r1892874 and follow-up commits avoid the (known) remote exploitation of CVE-2021-36160 as well as CVE-2021-40438. It happened that a vulnerability was reported against mod_proxy_wsgi so we fixed the flaw in mod_proxy_uwsgi (r1892805) and issued CVE-2021-36160, then further (internal-)analysis of the exploit showed that similar techniques could cause other flaws elsewhere so we fixed that in r1892874 and issued CVE-2021-40438. Even though we couldn't find another way to crash mod_proxy_uwsgi with r1892874 applied, the initial CVE-2021-36160 was still valid should another technique be used to trigger the bug in mod_proxy_uwsgi. Hope that helps. > > The regression discussed here is caused solely by the mod_proxy_uwsgi change > (r1892805). > > What patch does one need to apply to fix CVE-2021-36160? r1892805 will avoid the crash/DoS, but I wouldn't recommend to fix only CVE-2021-36160.. > > > Using one or the other depends on whether you want e.g."/uwsgi-ppfoo" to be > > passed too or not (whereas "/uwsgi-pp/foo" will be passed by both). > > Slight nitpick here, I believe 'ProxyPass /uwsgi-pp' won't match > '/uwsgi-ppfoo', and that the trailing slash/no-slash difference is whether > '/uwsgi-pp' would be 404 or passed :) Ah yes, sorry for the confusion. > > > However, I guess the following patch would remove multiple leading slashes > > [...] > > This would be something like this: > > Thanks, I confirm the second patch restores the previous behavior for my > test. > > Do you intend to apply this to the 2.4.x branch, or will you keep the new > (stricter) behavior there? It makes sense to apply this patch to "normalize" PATH_INFO, I didn't look at other PATH_INFO usages but there might be other places where this might happen too (mod_proxy_fcgi maybe?). In any case the leading '/' is introduced by the configuration so if the application can't cope with it I'd suggest to fix that first. Otherwise patches are always welcome ;) -- 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
