httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: Features requiring rebuild of server
Date Fri, 16 Feb 2001 16:09:31 GMT
On Thu, 15 Feb 2001, Frank Griffin wrote:
> rbb@covalent.net wrote:
> 
> > I do not believe we want to enable all modules by default in the
> > monolithic case.  Take the case of a sysadmin who reads about a security
> > whole in Apache.  They take a quick look at their config, and see no
> > mention of the module mentioned in the report.  They believe they are safe
> > at this point.  If that module is actually compiled statically in all
> > cases, then they may not be safe, but they may never know that.
> 
> Just out of curiosity, is there reason to believe that any of the
> modules are security holes ?  If so, is there reason to believe that
> they are security holes even if the configuration doesn't make the code
> callable at runtime ?  Is the worry that there is some sort of
> buffer-overrun hack which could cause this code to be executed in spite
> of an httpd.conf which disallows it ?  Would suexec-type warnings and a
> facility to disable automatic building of optional modules (which would
> not be the default) address the concerns of such sysadmins ?

There is no reason right now to believe that there are any security whole
in Apache.  If we release software we thought had security problems, we
would not be very good programmers.  Having said that, just because we
don't know of any security whole, doesn't mean that there aren't any, it
just means they haven't been found yet.

If we include a module in the Apache distribution, it will have code
run.  The only way to stop that from happening, is to not compile the code
in.  The module can be disabled, by adding ClearModuleList to the config
file, and not adding the module back into the server, but that module will
still have some of it's initilization functions called.

If we find a security whole in mod_rewrite's initilization routines, then
we have a security whole that the admin may not realize they are
suscpetible to.

> The bottom line is that even if I have to tell customers that today you
> have to reinstall, I can get back some credibility by saying that we
> have contributed code which will make this unnecessary, the committers
> have accepted it, and we expect it to be in version xxx.  I'd like to
> get some sense of whether the Apache Server community finds these
> changes acceptable within the design framework, or whether I'd just be
> wasting my time submitting them.  Also, I haven't worked in your code
> before, and would probably have to ask some questions, and I don't want
> to be wasting people's time if the resulting work isn't something you'd
> consider committing.

I think we would really need to see some of the code before we could
really say whether it would be accepted or not.  However, the Apache 1.3
tree is really in a maintenance cycle, and most, if not all, of our effort
is on Apache 2.0 at this point.  It is unlikely that patches for 1.3 will
be accepted and released quickly.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message