> If you're now trying to open this directory (or any file within)
> and enter any user / password combination, you'll get a
> hanging (death running) client. This is, because it's reading
> /dev/zero and searches for a colon (':') to separate
> the user name from the password field (mod_auth.c, get_pw(), line 127).
[...]
> Because also other authentication methods may be exploitable
> I would prefer to patch it in a way that it's no longer be
> available to open /dev/zero (or any other device) for reading,
> so I patched fpopen() in alloc.c:
perhaps you should stat the file and make sure its a normal file?
There may be other device files which cause problems by virtue
of having lots of data, or by blocking for long periods of time.
For example a blocking read on a dialup device that waits for
carrier sense on a modem. Is there any reason to allow device
files to be read from the config?
This may not stop all possible attacks. Normal files might be
used to indefinitely block the daemon. For example some systems
allow regular users to make NFS mounts. In this case an NFS
server can be brought up, mounted, then brought down. The
httpd reading an nfs mounted file would then block for a long
period of time while NFS times out. The same result can be
achieved by performing a denial of service attack against an already
existing NFS mount.
Are there other ways to cause long blocking times when reading
normal files? Do any common unix systems have mandatory file locking?
> Jan Wedekind
> UUNET Deutschland GmbH private: janat_private
Tim N.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:39:34 PDT