www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Wedekind <...@wedekind.de>
Subject mod_auth-any/1672: Authentication / .htaccess DoS attack
Date Wed, 14 Jan 1998 18:07:16 GMT

>Number:         1672
>Category:       mod_auth-any
>Synopsis:       Authentication / .htaccess DoS attack
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Wed Jan 14 10:10:01 PST 1998
>Originator:     jan@wedekind.de
>Release:        1.2.*
Solaris 2.x, Linux & any other Unix
(same report will be sent to bugtraq; this is the same splitted text)

At the beginning of the week (after the release of apache 1.2.5)
we discoverd a DoS attack in apache and (eventually) other / all (?)
httpd's. Many thanks to Bernard "sendmail" Steiner <bs@de.uu.net>,
who got the important idea.

For apache 1.2.x (and very sure all versions before), the
DoS may be exploited if both of the following conditions are true:

- the intruder has (at least FTP) write access to (at least)
  one public HTML directory

- per directory access (AccessFileName configuration directive)
  is enabled and the filename is known to the intruder
  (default is .htaccess)

This configuration will be found very often at private homepages
with FTP-Upload accounts.

Now just put a new .htaccess file to the Server with the 
following contents:

AuthType Basic
AuthName DoS Attack
AuthUserFile /dev/zero
<Limit GET POST>
order deny,allow
allow from all
require valid-user

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).

Now the intruder may stop this request in the browser (the server 
client process will still continue) and start a new one. The next
client will be forced to read /dev/zero.
Repeat this, until 'MaxClient' will be reached. Not only this server
will stop to work (e.g. the parent will wait for all further 
requests for any of it's child), but also the machine will 
going almost to hang with a CPU load of about MaxClient.
see Description
possible fixes:

a) workaround

Disable .htaccess in srm.conf by commenting out AccessFileName:
 (default is NULL in the apache distribution, e.g. disabled)

#AccessFileName .htaccess

b) patch to apache source

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:

kirk: ~/src/apache_1.2.4/src> gdiff -uw alloc.c.orig alloc.c
--- alloc.c.orig        Thu Jan  8 14:14:13 1998
+++ alloc.c     Fri Jan  9 13:37:21 1998
@@ -839,9 +839,14 @@
   FILE *fd = NULL;
   int baseFlag, desc;
+  struct stat buf;
+  if (   *mode != 'r' 
+      || (strcmp(name,"/dev/null") == 0)
+      || stat(name, &buf) == 0 && ((buf.st_mode & S_IFMT) == S_IFREG))
+  {
   if (*mode == 'a') {
     /* Work around faulty implementations of fopen */
     baseFlag = (*(mode+1) == '+') ? O_RDWR : O_WRONLY;
@@ -854,6 +859,7 @@
   } else {
     fd = fopen(name, mode);
+  } 
   if (fd != NULL) note_cleanups_for_file (a, fd);
[In order for any reply to be added to the PR database, ]
[you need to include <apbugs@Apache.Org> in the Cc line ]
[and leave the subject line UNCHANGED.  This is not done]
[automatically because of the potential for mail loops. ]

View raw message