Date: Mon, 5 Jan 1998 11:25:47 -0800 (PST)
From: Dean Gaudet <dgaudet@arctic.org>
To: new-httpd@apache.org
Subject: yet another DoS attack (was Re: Bug in URI parsing)
In-Reply-To: <Pine.LNX.3.96.980103202009.18893A-200000@leon.lander.es>
Message-ID: <Pine.LNX.3.95dg3.980105110818.30431E-100000@twinlark.arctic.org>
Organization: Transmeta Corp.
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED;
 BOUNDARY="1287860782-1450365357-883855169=:3593"
Content-ID: <Pine.LNX.3.96.980103202009.18893B@leon.lander.es>
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--1287860782-1450365357-883855169=:3593
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.3.96.980103202009.18893C@leon.lander.es>

On Sat, 3 Jan 1998, Alvaro Martinez Echevarria wrote:

> Hi there.
> This is my first message to the list (and I am on the list from
> just a couple of hours ago) so don't be too hard :-).
> I have found a bug in the URI parsing of apache 1.2.4 (the one I
> am working with), to be more specific in check_fulluri. The
> problem arises when a request like this is made to a host called
> myhost.mydomain.com:
> 
> GET http://myhost.mydomain.com HTTP/1.0

This looks right.  But you just reminded me of how ugly check_fulluri is.
In fact it's so ugly it is a DoS attack:

Set up a domain which has an NS record that's bogus (if you're lucky
and my secondaries have picked it up by the time you've read this,
dne.arctic.org is one such domain).  Then send the request "GET
http://dne.arctic.org/asdf HTTP/1.0" to the server a zillion times.
Instant DoS requiring very little bandwidth to set up.

dne.arctic.org. 	IN NS dns-ne.arctic.org.
dne-ns.arctic.org. 	IN A 126.0.0.1

The host 126.0.0.1 doesn't exist, there's no route for it, but named will
patiently block you out until various timeouts occur. 

Below is a hack against 1.3 that fixes this DoS.  But it's not the
correct fix.  The correct fix is to ask http_vhost "is this a name for
this server?".  That's a question that can be answered without doing DNS
imnsho.  If it's not a name for "this" server then damnit we should just
suffer the "inefficiency" of possibly proxying a request to ourselves.
Or better yet, when the proxy way later on discovers that it's about to
query itself it can do an internal redirect.  This proxy-specific code
should not be in the core.

Martin, what state is your uri parsing patch in?

Dean

Index: main/http_protocol.c
===================================================================
RCS file: /export/home/cvs/apachen/src/main/http_protocol.c,v
retrieving revision 1.172
diff -u -r1.172 http_protocol.c
--- http_protocol.c	1997/12/26 18:26:59	1.172
+++ http_protocol.c	1998/01/05 19:10:48
@@ -659,22 +659,6 @@
     else if (!strcmp(host, inet_ntoa(r->connection->local_addr.sin_addr))) {
         return (uri + r->hostlen);
     }
-    else {
-        /* Now things get a bit trickier - check the IP address(es) of
-         * the host they gave, see if it matches ours.
-         */
-        struct hostent *hp;
-        int n;
-
-        if ((hp = gethostbyname(host))) {
-            for (n = 0; hp->h_addr_list[n] != NULL; n++) {
-                if (r->connection->local_addr.sin_addr.s_addr ==
-                    (((struct in_addr *) (hp->h_addr_list[n]))->s_addr)) {
-                    return (uri + r->hostlen);
-                }
-            }
-        }
-    }
 
     return uri;
 }

--1287860782-1450365357-883855169=:3593--