httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: several messages (fwd)
Date Tue, 14 Jan 1997 01:08:03 GMT
On Mon, 13 Jan 1997, sameer wrote:

> > If stat were passed a path like that which was too long, it would fail and
> > things would end up being bad.  However, that is stripped out before we
> > get to the stat call because it has a meaning in URLs; same thing as /../,
> > which is not necessarily the same meaning as in the underlying filesystem 
> > so it has to be dealt with earlier. 
> 	The stripping is done by apache, or the browser? If it's the
> browser, then we can't trust that it will be stripped, of course.


> > sameer writes:
> > >        Perhaps rather than checking for ENOENT and ENOTDIR, check for
> > >ENAMETOOLONG? (Or was that already discussed, and tossed for
> > >portability?)
> > 
> > I'm not sure portability is an issue, but it goes against basic security
> > principles.  Only allow what you know is good; don't just disallow what
> > you know is bad.
> 	In this situation I don't think it's that clear, because it
> isn't necessarily a 'basic security principle' issue. I haven't been
> looking at this closely until last night, so I'll pass on this --
> you've been looking at this longer.

Assuming that letting people see a directory listing is a security hole (I
don't think it is a huge one, but it is there and many morons and some
people who know what they are doing rely on people not being able to do
it.), then you should always deny everything and only allow what you know
is safe.  I think that applies here because some odd OS may add another
error (eg. ETOOMANYSLASHES) which is a stat() failure as opposed to saying
it doesn't exist.  If you assume that ENAMETOOLONG is the only one which
could be a problem, you leave yourself open to the unknown.

If you assume that ENOENT and ENOTDIR are the only ones which say "that
file can't exist", then if some OS adds another error (eg. ECANNEVEREXIST)
it fails on the side of being too secure.

If you do the latter, you find out about the problem as soon a someone
tries to use it and you can fix it; after the first few times of being too
strict (like 1.1.2) you eventually get it right, at the expense of a few
buggy (but a well-defined bug) releases.  If you do the former, you find
out that you are wrong when someone posts an exploit.

View raw message