Subject: #100: DNS Spoofing / Rebinding

From: Mark Nottingham <[email-masked]>
Date: Sun, 17 Jul 2011 11:33:52 +1000

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/100>

We've had this ticket open for a while now.

Relevant text in our current draft:
  <http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-15#section-11.4>

AIUI DNS pinning is no longer considered an adequate defence against rebinding, and the current advice is for servers to verify the Host header.

If that's correct, I think we can close this issue with no change.

Thoughts? We should also probably circulate with some security folk.

--
Mark Nottingham   http://www.mnot.net/

---

From: Amit Klein <[email-masked]>
Date: Sun, 17 Jul 2011 08:48:55 +0300

In the past (and this may re-incarnate) it was possible for clients to
provide arbitrary Host headers with HTTP requests, thus rendering the
Host header verification defense somewhat useless. See e.g.:
http://archive.cert.uni-stuttgart.de/bugtraq/2006/09/msg00090.html

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 17 Jul 2011 16:03:18 +1000

My understanding was that these holes had been closed, and that while there are undoubtedly still some clients out there that allow Host headers to be set, it's not an attractive attack to make now. What's the current state of things?

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 17 Jul 2011 08:14:39 +0200

> My understanding was that these holes had been closed, and that while there are undoubtedly still some clients out there that allow Host headers to be set, it's not an attractive attack to make now…

I know a number of places who still use Apache 1.3 + mod_proxy as the front
layer for SSL+cache. This component did not have the ProxyPreserveHost
directive, and as such, the common deployment model consists in binding it
to one IP address and forwarding everything received on that IP to the next
hop with a rewritten Host header.

I'm realizing that the security there only relies on the host name in the
SSL certificate. Once that's said, I wonder if we need to care about the
risk of abusing a non-SSL site, which may be abused a number of different
ways too. The only difference can lie in mass-attacks, but it's not obvious
to me what kind of issues we might face with an uncontrolled server returning
contents for a different host.

Regards,
Willy

---

From: Chris Weber <[email-masked]>
Date: Sun, 17 Jul 2011 00:23:38 -0700

>> http://archive.cert.uni-stuttgart.de/bugtraq/2006/09/msg00090.html

Most of these holes have been closed.  Save for the exceptions where 
similar bugs will probably continue to surface, which is sounds like 
Amit was alluding to, as something recently did 
<http://weblog.rubyonrails.org/2011/2/8/csrf-protection-bypass-in-ruby-on-rails>.

Having servers verify the Host header still seems valuable as defense in 
depth but not as the panacea of course.

-Chris

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 19 Jul 2011 23:01:13 +1000

Right.

I think my concern at this point is that whatever we put into the spec, it's likely to be outdated fairly soon. I could see publishing a separate RFC (one that updates HTTP) to address this class of problem if/when that's possible; otherwise my gut feeling is that the most we can do is put a warning in that describes the problem, and list some mitigation strategies, stressing that they're not a complete fix.

Make sense?

On 17/07/2011, at 5:23 PM, Chris Weber wrote:

> Most of these holes have been closed.  Save for the exceptions where similar bugs will probably continue to surface, which is sounds like Amit was alluding to, as something recently did <http://weblog.rubyonrails.org/2011/2/8/csrf-protection-bypass-in-ruby-on-rails>.
> 
> Having servers verify the Host header still seems valuable as defense in depth but not as the panacea of course.
> 
> -Chris
>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 29 Jul 2011 13:41:35 -0700

Lacking specific proposals on this, I'm closing as WONTFIX. If someone is willing to write a proposal, we can reopen.

---

From: Henrik Nordström <[email-masked]>
Date: Sat, 30 Jul 2011 01:12:56 +0200

sön 2011-07-17 klockan 11:33 +1000 skrev Mark Nottingham:
> AIUI DNS pinning is no longer considered an adequate defence against
> rebinding, and the current advice is for servers to verify the Host
> header.

Regarding issue #100, I think it's a proper action to align
specifications with current implementations a bit by dropping the MUST
level requirement from p1 11.4, deleting the following text entirely:

   If HTTP clients cache the results of host name lookups in order to
   achieve a performance improvement, they MUST observe the TTL
   information reported by DNS.

   If HTTP clients do not observe this rule, they could be spoofed when
   a previously-accessed server's IP address changes.  As network
   renumbering is expected to become increasingly common [RFC1900], the
   possibility of this form of attack will grow.  Observing this
   requirement thus reduces this potential security vulnerability.

with no replacement or other changes to the text. Leaving it entirely up
to implementations how they cache DNS lookups if they cache. The other
requirements are all SHOULD level leaving the door open to cache if one
want's to.

As already noted the section in general is both bad advice in terms of
security and the opposite of what most client implementations do today.
And in issues like this it's better to be silent than to give bad
advises.

But even with this text deleted the title of the section is questionable
except for the initial paragraph.

For domains using DNSSec the situation is quite different. There
everything said in p1 11.4 is true, secure and technically correct. But
then the title is completely irrelevant.

So here is another proposal. Shorten and rewrite p1 4.2 as follows

        Clients using HTTP rely heavily on the Domain Name Service, and
        are thus generally prone to security attacks based on the
        deliberate misassociation of IP addresses and DNS names not
        protected by DNSSec. Clients need to be cautious in assuming the
        validity of an IP number/DNS name association unless the
        response is protected by DNSSec.

removing all advices on how to (not) to cache DNS responses or any
implications that there is any continuing relation. And in lack of a
usable reference keep silent on the bit of how to be cautious.

Regarding the mentioned Host header validation in p1 4.2 #3, that's not
a new requirement. Been there since 2616 at least. And still most
implementations do have a catch-all default directly violating this.

Regards
Henrik

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 30 Jul 2011 07:48:04 -0700

Thanks, Henrik.

>        response is protected by DNSSec.

I like this one; others?

---

From: Julian Reschke <[email-masked]>
Date: Sun, 31 Jul 2011 13:24:41 +0200

On 2011-07-30 01:12, Henrik Nordström wrote:
> ...

Sounds good -- but that's for 11.4, not 4.2, right? Also, do we need a 
new section title? "DNS-related Attacks"?

Finally, we'll need a ref for DNSSec. RFC 4033?

Best regards, Julian