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/

Re: SSLSrvConfigRec shared

2017-09-20 Thread Stefan Eissing 

> Am 20.09.2017 um 12:33 schrieb Yann Ylavic :
> 
> On Wed, Sep 20, 2017 at 12:09 PM, Stefan Eissing
>  wrote:
>> 
>> Is there some better way?
> 
> I would go with the usual/unconditional per server config (and hence
> merging), trade simplicity vs a few memory space...

Not sure I get your dift here.

server/config.c calls merge_server_configs() for each non-base server_rec
and that one copies the config pointer from base if the vhost has none. 
if there is one, it merges.

Now, are you speaking of changing that for all modules? Add a flag to "struct 
module"
or solve it in mod_ssl post_config?

Cheers,
Stefan


> Regards,
> Yann.

Re: SSLSrvConfigRec shared

2017-09-20 Thread Yann Ylavic 
On Wed, Sep 20, 2017 at 12:09 PM, Stefan Eissing
 wrote:
>
> Is there some better way?

I would go with the usual/unconditional per server config (and hence
merging), trade simplicity vs a few memory space...

Regards,
Yann.

Re: AP_ENABLE_EXCEPTION_HOOK

2017-09-20 Thread Yann Ylavic 
On Wed, Sep 20, 2017 at 10:51 AM, Stefan Eissing
 wrote:
> Trying to tighten some compiler warnings and gcc complains:
>
> /opt/httpd/trunk/include/mpm_common.h:390:5: error: 
> "AP_ENABLE_EXCEPTION_HOOK" is not defined [-Werror=undef]
>  #if AP_ENABLE_EXCEPTION_HOOK
>
> We seem to "#undef" this. Should the check in mpm_common.h not be #ifdef then?

-Wundef I guess.

For completeness we probably should:
#if defined(AP_ENABLE_EXCEPTION_HOOK) && AP_ENABLE_EXCEPTION_HOOK

SSLSrvConfigRec shared

2017-09-20 Thread Stefan Eissing 
mod_ssl's server_rec configurations (SSLSrvConfigRec) are shared between vhost 
and base server *iff* there are no SSL* directives used inside a VirtualHost. 
This is not really a good idea since mod_ssl modifies these recs in its 
post_config hook. This looks currently harmless, e.g. setting sc->vhost_id n 
times (but the vhost_id is wrong for all but the last). With adding 
certificate/keys in post-config (mod_md) this sharing can no longer happen.

To be precise: this is a side effect of a global "SSLEngine" config. The 
old-skool "SSLEngine on" in each vhost will cause every server_rec to have its 
own SSLSrvConfigRec instance and things work.

Now, I would like both cases to work. Does anyone have a recommendation? My 
current thoughts go like (pseudo code):

if (server != base_server && sslconf(server) == sslconf(base_server)) {
   newconf = conf_merge(new_server_conf(), sslconf(base_server));
   ap_set_module_config(server, newconf);
}

Is there some better way?

Cheers,

Stefan

AP_ENABLE_EXCEPTION_HOOK

2017-09-20 Thread Stefan Eissing 
Trying to tighten some compiler warnings and gcc complains:

/opt/httpd/trunk/include/mpm_common.h:390:5: error: "AP_ENABLE_EXCEPTION_HOOK" 
is not defined [-Werror=undef]
 #if AP_ENABLE_EXCEPTION_HOOK

We seem to "#undef" this. Should the check in mpm_common.h not be #ifdef then?