Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
MIME-Version: 1.0
From: William A Rowe Jr <wrowe@rowe-clan.net>
Date: Wed, 20 Sep 2017 11:36:56 -0500
Message-ID: <CACsi253RfX7OT5NhZCKRru2JpOKoscux=jzDzJOnbcF31XHmMw@mail.gmail.com>
Subject: Understanding OptionsBleed
To: httpd <dev@httpd.apache.org>
Content-Type: text/plain; charset="UTF-8"
archived-at: Wed, 20 Sep 2017 16:37:07 -0000

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/