Hi Bill, nice summary, totally agreed.
Thanks! On Wed, Sep 20, 2017 at 6:36 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > So as most people have correctly identified, this defect has existed > for an incredibly long time. > > But how it is triggered and avoided would help us to correctly study > unexpected behaviors. > > OPTIONS * - won't trigger the defect, .htaccess should not be examined. > > OPTIONS / - may trigger the defect, because the path is traversed and > one or more .htaccess files may be processed. > > In all versions, <Limit > of the standard methods do not trigger the > defect. Only <Limit > of any unregistered methods in an allowed > .htaccess file will trigger the defect. > > In 2.4.23 and prior including all 2.2/2.0, "HEAD" was not registered, > but would not be registered by <Limit because we first tested method > number (which returned the GET method ID.) In 2.4.25 and 2.4.26, HEAD > was registered but the Allow header constructor duplicated GET -> HEAD > and HEAD --> HEAD resulting in four methods listed, fixed already in > 2.4.27. > > In order to avoid the defect with trusted .htaccess authors; > > In 2.2.31 and prior (all 2.0) or 2.4.23 and prior we can use an > otherwise no-op <Limit block in the global httpd.conf for non-standard > methods that are expected to occur in .htaccess - this avoids > registering them at request time. > > In 2.2.32+ / 2.4.25+ we can use RegisterHttpMethod in the global > httpd.conf for non-standard methods in .htaccess - this avoids > registering them at request time. > > It is not possible to avoid this defect with untrusted/malicious > .htaccess authors without disabling .htaccess files, patching or > upgrading to version 2.4.28. > > Provided AllowOverride is None, and AllowOverrideList does not include > "<Limit", the server should be protected, but I haven't played with > this theory; https://httpd.apache.org/docs/2.4/mod/core.html#allowoverridelist > > The httpd server cannot ever address every possible aspect of > malicious .htaccess authoring, and the project has reiterated this > message multiple times, leading to a vulnerability assessment of 'low' > severity in all cases that weren't disputed as not vulnerabilities > whatsoever; > > https://www.cvedetails.com/cve/CVE-2011-3607/ > https://www.cvedetails.com/cve/CVE-2011-4415/ > https://www.cvedetails.com/cve/CVE-2009-1195/ > https://www.cvedetails.com/cve/CVE-2004-2343/ > https://www.cvedetails.com/cve/CVE-2004-0747/
