httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: summary of security issues
Date Sat, 04 Jan 1997 10:08:27 GMT
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.


Mime
View raw message