Subject: Fodder for security issues document (was: dns binding)

From: Lisa Dusseault <[email-masked]>
Date: Thu, 2 Aug 2007 12:39:22 -0700

This issue is part HTML, part URL construction rules, part DNS and of  
course a little bit of HTTP

lisa

Begin forwarded message:

>
> http://crypto.stanford.edu/dns/
>
> DNS rebinding attacks subvert the same-origin policy of browsers and
> convert them into open network proxies. These attacks can be used to
> circumvent firewalls and are highly cost-effective for sending spam
> e-mail and defrauding pay-per-click advertisers, requiring less than
> $100 to temporarily hijack 100,000 IP addresses. We show that a
> well-known, existing defense against these attacks, called "DNS
> pinning", is ineffective in modern browsers. The primary focus of this
> work, however, is the design of strong defenses against DNS rebinding
> attacks that protect modern browsers. For the near-term, we suggest
> easy-to-deploy defenses that prevent large-scale exploitation by
> patching individual plug-ins and improving the robustness of browser
> DNS pinning strategies. For the long-term, we propose two solutions,
> circumvention-resistant firewalls and host name authorization, that
> fix the root cause of DNS rebinding vulnerabilities by preventing the
> attacker from naming a target server.
>

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 06 Aug 2007 17:35:34 +0200

> course a little bit of HTTP

Fortunately quite easy to protect from within the current HTTP/1.1
specs. Only requirement is that one can assume clients supports HTTP/1.1
or at least HTTP/1.0 + Host header, which is all known browsers and
nearly all other known user-agents.

HTTP solution: Make the web server only respond on known site names, not
a catch-all "defaultsite".

Regards
Henrik

---

From: David Morris <[email-masked]>
Date: Mon, 6 Aug 2007 12:51:36 -0700 (PDT)

> a catch-all "defaultsite".

I must be dense ... I don't understand how an attack which returns invalid
IPs for a host is mitigated by proper honoring of host header info.

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 06 Aug 2007 22:30:05 +0200

> IPs for a host is mitigated by proper honoring of host header info.

It blocks information theft in the attack vectors where the attacker's
software/scripts can not gain direct network access and only have
validated HTTP clients with working host/domain based restrictions to
work with.

Ofcourse it does not protect against DoS botnets, or the other
information theft attack vectors where the attacker gains direct network
access and can construct the HTTP request freely, or where
implementation bugs allows the attacker to bypass host/domain based
restrictions. There is very little which can be done at the HTTP level
in these cases as the requests looks perfectly valid on the server side.

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 09 Aug 2007 14:42:16 +0200

Been reading and thinking a bit more on the DNS binding problem after
the reminder by Lisa, and came to the conclusion that RFC2616
recommendations and actual implementation and security concerns is quite
far apart on this.

RCF2616 15.3 "DNS Spoofing" recommends the exact opposite of DNS
binding. Any client implementing those recommendations is quite
vulnerable to the discussed issues. This makes me wonder if 15.3 perhaps
should be dropped from the specifications. Not many user-agents is
following the recommendation found there (certainly none of the main
browser vendors), and it's recommendations also is not very effective
against what 15.3 tries to protect from (DNS poisoning). The protection
from DNS poisoning 15.3 tries to achieve is best addressed at the DNS
resolver layer, not HTTP application implementation.

The recommendations in 15.3 is sane from a technical perspective, and
also close to obviously "correct" from a technical perspective, but
unfortunately opens a information theft security issue by using
scripting capable user agents using hostname based access checks to jail
the executed scripts. So having this in the specs is counter to actual
implementation experience.

Additionally viewing 15.3 as a security measure is imho not very useful
as it doesn't really improve the security aspects by any noticeable
amount at any level.

So in the end it's better to leave this to implementation detail I
think, leaving it out of the protocol specifications I think.

But this said, the HTTP solution of not allowing servers to answer
requests for "other" sites do solves quite a lot of the security
concerns regarding information theft using HTTP. The rest is client
implementation details to ensure active content is properly jailed.

Regards
Henrik