summary of security issues

[Marc Slemko <ma...@znep.com>]

Below is a summary of what the remaining security issues before 1.2
are from my perspective.  Comments are needed on the last issue
especially.

symlinked log files: no easy and comprehensive solutions for
	preventing apache from overwriting files by symlinking from
	the log file.  Apache could check to see if the logfile is a
	link before opening it, which would reduce the risk since then
	someone would need to exploit a race condition or be able to
	do a hard link.  Are there people actually using symlinks for
	logfiles in normal use that this would break things for?  The
	conclusion seems to be to document this problem and that's
	good enough, at least for now.  If this is not done magically
	before I get some time, I will add it to where I think it
	would be appropriate in the docs and send in a diff.  The
	problem with the symlinked lock file in /tmp has already
	been fixed.

suexec: currently is dangerously broken WRT userdir executions and
	must not be released as is.  Discussion is ongoing.  Some
	changes are tenatively planned, but I think more are needed.  

buffer overflows: there are a number of overflows that are known to be
	potential trouble makers, some that are known to be harmless,
	and a whole lot that are in the middle.  Not everyone is happy
	with my suggested fixes as is, for some valid reasons (ie.
	magic numbers in sprintfs are bad especially when we are
	practically at a release).  I would be happier if they could
	be converted to a snprintf type thing; the one from the
	libraries with xinetd has been suggested and looks workable,
	however it introduces more possibly broken code, and likely
	code that won't compile some places.

	A possible procedure:
		- replace sprintf calls with mysnprintf or whatever
		- make the xinetd snprintf equiv. compile as
		  mysnprintf.
		- possibly have mysnprintf just call snprintf if
		  available.
		- large note in the docs, "if mysnprintf don't
		  compile, do <foo> which will change a macro to use
		  sprintf instead then mail us why it wouldn't
		  compile"; it leave the security holes if they have
		  to use sprintf, but makes the thing compile with
		  a minimal effort.

	I need to know how many people think they could support
	something like that, depending on how well it is implemented
	of course.  I am not going to spend my time right now
	playing with that idea if people don't want to take the
	risk.  It is not the ideal thing to be doing right before a
	release but not fixing them isn't ideal either.

Re: summary of security issues

[Marc Slemko <ma...@znep.com>]

On Sat, 4 Jan 1997, Dean Gaudet wrote:

> I wonder if we could "point" to an snprintf implementation, like the glibc
> one, maybe tweaked a bit.  So if it fails say ... you can #define it to
> sprintf or you can get this snprintf that is covered by the gnu library
> license.

I am not inclined to think overly highly of glibc.  In any case, it could
take some work to yank the snprintf out of glibc, because we really can't
expect people to use the whole glibc.  I'm not sure that a #define will
work, it may need to be an actual subroutine.

> Maintaining an snprintf shouldn't be much harder than the bprintf we've
> already got... should it?

I am more concerned about introducing it than maintaining it.  I am not
happy with waiting until post-1.2 to put it in and introducing it could
cause some problems.

> 
> symlinked log files is equally an issue with things like syslog, yet
> there's no compelling movement to fix that in some way... Given the talk

No.  I don't know of any syslog's that create their own files, although
there may be a few out there.  Web servers are somewhat unusual in that it
is normal to have lots of log files for different users (ie. virtual
domains), and those log files may be treated by some as if the user should
be able to do whatever they want with them.

> recently in BUGTRAQ maybe we can just lift someone else's solution.  It's
> a pain to get right across architectures though.  We might get further by

Problem is that I don't think there is a complete solution.  We need to
atomically check that the file is not a symlink/hardlink to something and
get a file descriptor on it.  If we open a fd, we can use fstat to check
it out and make sure there are no hard links.  But we are stuck for
checking if it is a link.  To do that, we need to use lstat.  If we had a
flstat, that would be cool but we don't.  I cna't think of any time we
could use lstat without exposing a possible race condition.  It can be
made better than it is, but I am doubtful that it can be fixed.

> writing a "securing your apache server" FAQ.  We should mention things
> like the log files, a restrictive <Directory />, symlinks in document
> trees, dns attacks. 

There is a start of something like that under http://www.apache.org/docs,
but it could be expanded.  However, putting important things there is not
enough; there needs to be a warning by the directive that most applies in
the manual and possibly a warning in the changes file.

Re: summary of security issues

[Dean Gaudet <dg...@arctic.org>]

I wonder if we could "point" to an snprintf implementation, like the glibc
one, maybe tweaked a bit.  So if it fails say ... you can #define it to
sprintf or you can get this snprintf that is covered by the gnu library
license.

Maintaining an snprintf shouldn't be much harder than the bprintf we've
already got... should it?

symlinked log files is equally an issue with things like syslog, yet
there's no compelling movement to fix that in some way... Given the talk
recently in BUGTRAQ maybe we can just lift someone else's solution.  It's
a pain to get right across architectures though.  We might get further by
writing a "securing your apache server" FAQ.  We should mention things
like the log files, a restrictive <Directory />, symlinks in document
trees, dns attacks. 

Dean

On Sat, 4 Jan 1997, Marc Slemko wrote:

> Below is a summary of what the remaining security issues before 1.2
> are from my perspective.  Comments are needed on the last issue
> especially.
> 
> symlinked log files: no easy and comprehensive solutions for
> 	preventing apache from overwriting files by symlinking from
> 	the log file.  Apache could check to see if the logfile is a
> 	link before opening it, which would reduce the risk since then
> 	someone would need to exploit a race condition or be able to
> 	do a hard link.  Are there people actually using symlinks for
> 	logfiles in normal use that this would break things for?  The
> 	conclusion seems to be to document this problem and that's
> 	good enough, at least for now.  If this is not done magically
> 	before I get some time, I will add it to where I think it
> 	would be appropriate in the docs and send in a diff.  The
> 	problem with the symlinked lock file in /tmp has already
> 	been fixed.
> 
> suexec: currently is dangerously broken WRT userdir executions and
> 	must not be released as is.  Discussion is ongoing.  Some
> 	changes are tenatively planned, but I think more are needed.  
> 
> buffer overflows: there are a number of overflows that are known to be
> 	potential trouble makers, some that are known to be harmless,
> 	and a whole lot that are in the middle.  Not everyone is happy
> 	with my suggested fixes as is, for some valid reasons (ie.
> 	magic numbers in sprintfs are bad especially when we are
> 	practically at a release).  I would be happier if they could
> 	be converted to a snprintf type thing; the one from the
> 	libraries with xinetd has been suggested and looks workable,
> 	however it introduces more possibly broken code, and likely
> 	code that won't compile some places.
> 
> 	A possible procedure:
> 		- replace sprintf calls with mysnprintf or whatever
> 		- make the xinetd snprintf equiv. compile as
> 		  mysnprintf.
> 		- possibly have mysnprintf just call snprintf if
> 		  available.
> 		- large note in the docs, "if mysnprintf don't
> 		  compile, do <foo> which will change a macro to use
> 		  sprintf instead then mail us why it wouldn't
> 		  compile"; it leave the security holes if they have
> 		  to use sprintf, but makes the thing compile with
> 		  a minimal effort.
> 
> 	I need to know how many people think they could support
> 	something like that, depending on how well it is implemented
> 	of course.  I am not going to spend my time right now
> 	playing with that idea if people don't want to take the
> 	risk.  It is not the ideal thing to be doing right before a
> 	release but not fixing them isn't ideal either.
> 
> 
>