You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Alvaro Martinez Echevarria <al...@lander.es> on 1998/01/03 21:30:49 UTC
Bug in URI parsing
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
As you can see, the URL is given in http://host form, with an
empty path. The effect of this request is that (at least with
1.2.4) apache complains about an unexistent "/host" file. The bug
is in "check_fulluri" (located in http_protocol), where the
return value of the function "ind" (util.c) is not checked to be
positive or zero. The bug only arises if the request is
considered local by the server (if it is not local, the URI is
returned intact by the code in check_fulluri).
The question now is: is that URL legal? I was not sure, but after
taking a look at a few RFCs, now I think it is, although it
shouldn't be common. According to RFC 1738 (Uniform Resource
Locators), when in an HTTP URL ``neither <path> nor <searchpart>
is present, the "/" may also be omitted''. And also according to
RFC 2068 (HTTP/1.1), an absent abs_path in an HTTP absoluteURI
must be interpreted as "/", as long as the request is presented
at the origin server (but if the request is to be forwarded to
a proxy, it should not be rewritten).
I've written a tiny patch that seems to solve the problem. I have
modified check_fulluri and also parse_uri (both in
http_protocol.c), because we can only rewrite the uri after
deciding that the request is local (the "else" block in
parse_uri). It applies to 1.2.4, I don't know if it will fit into
1.3.X. The patch is so small that nothing else should be
affected. If it is included in the next release, this could be
added to the CHANGES:
*) Fixed a bug in URL parsing that caused a wrong decoding of
URLs with empty paths. [ Alvaro Mart�nez Echevarr�a
<al...@lander.es> ]
By the way, the proxy module seems to behave correctly about all
this only when making the request to the origin server. But if
ProxyRemote is used, the URL is rewritten (to add a trailing
"/"), and that is not correct (I think). Anyway that is a
HTTP/1.1 proxy matter, so I suppose it's not very important.
Regards.
.------------------------------------------------------------------.
| Alvaro Mart�nez Echevarr�a | LANDER SISTEMAS |
| alvaro@lander.es | P� Castellana, 121 |
`--------------------------------| 28046 Madrid, SPAIN |
| Tel: +34-1-5562883 |
| Fax: +34-1-5563001 |
`---------------------------------'
Re: yet another DoS attack (was Re: Bug in URI parsing)
Posted by Dean Gaudet <dg...@arctic.org>.
Yup, typo in my post, I meant dns-ns.arctic.org.. BTW it looks like my
zone update has made it around to all my secondaries so you can use
"dne.arctic.org" whenever you want to test a name that'll take Way Too
Long to Resolve.
Dean
On Mon, 5 Jan 1998, Ben Laurie wrote:
> Dean Gaudet wrote:
> > dne.arctic.org. IN NS dns-ne.arctic.org.
> > dne-ns.arctic.org. IN A 126.0.0.1
>
> I presume the first should be dne-ns, or the second should be dns-ne.
>
> Cheers,
>
> Ben.
>
> --
> Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
> Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
> and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
> A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
> London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
>
Re: yet another DoS attack (was Re: Bug in URI parsing)
Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
> dne.arctic.org. IN NS dns-ne.arctic.org.
> dne-ns.arctic.org. IN A 126.0.0.1
I presume the first should be dne-ns, or the second should be dns-ne.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: yet another DoS attack (was Re: Bug in URI parsing)
Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
> Oh yeah, also due to negative DNS caching, to set up a full attack against
> check_fulluri() you may need several hundred bogus DNS records. But that
> doesn't seem to be necessary against my bind-8.1.1 server, I get a 63s
> timeout on every request to dne.arctic.org.
I presume negative DNS caching doesn't cache failure to contact the NS,
only failure of that NS to return a response for the query (or, more
exactly, the NS returning an empty response).
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: yet another DoS attack (was Re: Bug in URI parsing)
Posted by Dean Gaudet <dg...@arctic.org>.
I should also add that you can easily set yourself up for similar DoS
attacks with 1.3 using "allow from domain" or "deny from domain". In that
case you need control of your reverse DNS, and you simply point your
reverse at some bogus address. Then the server will chunk when it tries
to double-reverse your address. So you attack by requesting lots of URLs
that require double-reverse.
In general though the folks with control over reverse DNS have much better
things to do with their time. So this maybe isn't as big an issue. And
it's an attack against tcpwrappers as well so we're not alone on this one.
Forward DNS on the other hand is in the hands of lots of devious folks.
Oh yeah, also due to negative DNS caching, to set up a full attack against
check_fulluri() you may need several hundred bogus DNS records. But that
doesn't seem to be necessary against my bind-8.1.1 server, I get a 63s
timeout on every request to dne.arctic.org.
Dean
yet another DoS attack (was Re: Bug in URI parsing)
Posted by Dean Gaudet <dg...@arctic.org>.
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;
}
Re: Bug in URI parsing
Posted by Dean Gaudet <dg...@arctic.org>.
D'ohh, this slipped by without being committed... I just put it in
1.2.7-dev. It's already fixed in a different way in 1.3. Thanks.
Dean
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
>
> As you can see, the URL is given in http://host form, with an
> empty path. The effect of this request is that (at least with
> 1.2.4) apache complains about an unexistent "/host" file. The bug
> is in "check_fulluri" (located in http_protocol), where the
> return value of the function "ind" (util.c) is not checked to be
> positive or zero. The bug only arises if the request is
> considered local by the server (if it is not local, the URI is
> returned intact by the code in check_fulluri).
>
> The question now is: is that URL legal? I was not sure, but after
> taking a look at a few RFCs, now I think it is, although it
> shouldn't be common. According to RFC 1738 (Uniform Resource
> Locators), when in an HTTP URL ``neither <path> nor <searchpart>
> is present, the "/" may also be omitted''. And also according to
> RFC 2068 (HTTP/1.1), an absent abs_path in an HTTP absoluteURI
> must be interpreted as "/", as long as the request is presented
> at the origin server (but if the request is to be forwarded to
> a proxy, it should not be rewritten).
>
> I've written a tiny patch that seems to solve the problem. I have
> modified check_fulluri and also parse_uri (both in
> http_protocol.c), because we can only rewrite the uri after
> deciding that the request is local (the "else" block in
> parse_uri). It applies to 1.2.4, I don't know if it will fit into
> 1.3.X. The patch is so small that nothing else should be
> affected. If it is included in the next release, this could be
> added to the CHANGES:
>
> *) Fixed a bug in URL parsing that caused a wrong decoding of
> URLs with empty paths. [ Alvaro Mart�nez Echevarr�a
> <al...@lander.es> ]
>
> By the way, the proxy module seems to behave correctly about all
> this only when making the request to the origin server. But if
> ProxyRemote is used, the URL is rewritten (to add a trailing
> "/"), and that is not correct (I think). Anyway that is a
> HTTP/1.1 proxy matter, so I suppose it's not very important.
>
> Regards.
>
> .------------------------------------------------------------------.
> | Alvaro Mart�nez Echevarr�a | LANDER SISTEMAS |
> | alvaro@lander.es | P� Castellana, 121 |
> `--------------------------------| 28046 Madrid, SPAIN |
> | Tel: +34-1-5562883 |
> | Fax: +34-1-5563001 |
> `---------------------------------'
>
>