[...]
>
> And (most important):
>
> - AllowOverride has been set up to allow AuthConfig overrides in an
> untrusted users directory.
>
> This is a serious configuration error. AllowOverride can be used to give
> users access to very considerable portions of the server setup. Untrusted
> users should have no (or strictly limited) access to the server
> configuration. Fully enabled .htaccess files can easily be abused to lock
> up or bring down the server or circumvent security restrictions in many
> different ways!
I don't buy that argument. Apache is configurable for a reason. It isn't
just AuthConfig that can cause this sort of problem. Having _anything_
other than "AllowOverride None" still allows this to work, and even if you
do have None then there are other similar attacks.
You have to keep in mind that the example posted is just an _example_ of
things that can be done. Avoiding the particular example doesn't fix the
underlying cause. While it is true that you have much better protection
against denial of service, and other, attacks by not allowing your users
to do anything, you should not be required to do so to run a server that
takes more than a few seconds effort to make unusable. Yes, there are
always denial of service attacks possible, but more can and should be done
to guard against them without disabling all sorts of very useful features.
On Thu, 15 Jan 1998, Don Lewis wrote:
[...]
> This may still be exploitable through a race condition. If the
> user has shell access, he could specify the name of a symlink
> in the .htaccess file. If the user can update the symlink to
> change it so that it points to /dev/zero between the stat()
> and the fopen(), he can still provoke the DoS. This is definitely
> harder to exploit, but if you change the code to do an open(),
> fstat() the resulting file descriptor, and finally fdopen() the
> descriptor if fstat() returns a satisfactory result, then the
> race condition is avoided.
Yes. I'm not overly worried about exploiting it since it, in practice,
requires shell access to the machine. If you have that, then something
like a sparse file is a heck of a lot easier and does the same thing.
> There is still a less severe DoS possibility if the user specifies
> a large colon-less file. It would probably be wise for get_pw()
> give up if it's reading from a bogus looking file.
The size of lines read from such files is limited to 8k anyway, so simply
detecting if you have reached the end of buffer before the end of line and
aborting if so will prevent excessive reading of binary files. Doing a
nonblocking open (as Alan Cox suggested) will (usually, not always) stop
things like named pipes, devices that block, etc. from hanging you up.
This doesn't stop large textfiles from causing problems, but that may or
may not be a problem. I'm still thinking about it. Refusing to open
things other than regular files is good, but it is simply a question of if
the overhead is necessary or if other methods can be sufficient.