Re: Understanding OptionsBleed

2017-09-21 Thread Yann Ylavic
On Thu, Sep 21, 2017 at 10:54 AM, Yann Ylavic  wrote:
> On Wed, Sep 20, 2017 at 6:36 PM, William A Rowe Jr  
> wrote:
>>
>> Provided AllowOverride is None, and AllowOverrideList does not include
>> "> this theory; 
>> https://httpd.apache.org/docs/2.4/mod/core.html#allowoverridelist
>
> I tested this and indeed the server is protected.
> This is IMHO the rigth way to control the content of .htaccess files
> from httpd.conf (i.e. a white-list).

Also note that AllowOverride containing "AuthConfig" implicitely
allows  in .htaccess, I think we should change this since
"Limit" can be specified explicitely in AllowOverride.


Re: Understanding OptionsBleed

2017-09-21 Thread Yann Ylavic
On Wed, Sep 20, 2017 at 6:36 PM, William A Rowe Jr  wrote:
>
> Provided AllowOverride is None, and AllowOverrideList does not include
> " this theory; https://httpd.apache.org/docs/2.4/mod/core.html#allowoverridelist

I tested this and indeed the server is protected.
This is IMHO the rigth way to control the content of .htaccess files
from httpd.conf (i.e. a white-list).


Re: Understanding OptionsBleed

2017-09-21 Thread Yann Ylavic
Hi Bill,

nice summary, totally agreed.

Thanks!


On Wed, Sep 20, 2017 at 6:36 PM, William A Rowe Jr  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,  of the standard methods do not trigger the
> defect. Only  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  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  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
> " 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/


Understanding OptionsBleed

2017-09-20 Thread William A Rowe Jr
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,  of the standard methods do not trigger the
defect. Only  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  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 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/