174590 - DNS "Pinning" behavior leads to security hole

Status: VERIFIED FIXED

(Core :: Security, defect)

Description

[Alan Eliasen]

The current behavior for DNS "pinning" leads to a security hole which allows
information to be sent to the wrong server, even without evil intent.  Scenario
is described below.

I believe that the current behavior to cache DNS entries forever is a standards
violation.  The standard for DNS, RFC 1035 states:

   - With the proper search procedures, authoritative data in zones
     will always "hide", and hence take precedence over, cached
     data.

   - Cached data should never be used in preference to
     authoritative data, so if caching would cause this to happen
     the data should not be cached.

DNS TTL information is not something that a single application should decide it
doesn't want to abide by.  

There has been some discussion that the current behavior is in response to a
"security" issue.  The current behavior, however, exchanges this for a more
common security problem, which occurs even if nobody is actively trying to steal
information.

 Refusing to abide by the TTL parameter from a DNS lookup is every bit as large
of a security hole, perhaps larger.  Using a cached, expired DNS lookup (such as
for those users using dynamic DNS services,) will end up sending the wrong
information to the wrong server, possibly an e-vil server.

Scenario:

1.  My home server, using DHCP, receives a dynamic IP address of 12.13.14.15

2.  I register the dynamic service myhome.dyndns.org to point to 12.13.14.15

3.  User Alice visits my web site, using Mozilla, and begins a transaction.

4.  My DHCP lease expires and I am given a new IP address of 12.200.200.200

5.  My server detects the change and automatically registers myhome.dyndns.org
to 12.200.200.200

6.  My old DHCP address, 12.13.14.15 is given to Bob Evil's computer.

7.  Alice finishes filling out a web form in Mozilla and submits it.  Mozilla
erroneously uses the cached IP address 12.13.14.15, and the data is incorrectly
sent to Bob Evil's computer.  

   The information sent may be stored in the HTTP log or may generate errors. 
Private cookies that allow the Bad Guys to forge Alice's session or impersonate
Alice will also be sent.

This bug also creates two major usability problems for Mozilla:

1.) I run a server from home on my DSL line.  My IP address changes
periodically, so I use a dynamic DNS service like dyndns.org.  This allows me to
use the same fully-qualified domain name that always maps to my home server.  It
works perfectly in every single application *except* Mozilla, which gives "Could
not connect to server" errors because it caches DNS entries forever.  Shutting
down the browser works, but it makes everyone think that my server is actually
down.  No other browser has this problem.

   This happens quite commonly with a dynamic IP address.  I've ended up hitting
other peoples' DSL routers (if they have no web site set up) instead of my own
server with Mozilla, even though I've registered a new IP address, and DNS
lookup gives the proper new address.

2.) Load-balanced or fail-safe corporate server farms that use round-robin DNS
are actually made *less* reliable using Mozilla's DNS caching mechanism.  If one
server is overloaded, taken down, or crashes, Mozilla is unable to connect using
the old, expired DNS entry.  This is one reason that some companies don't like
to use Mozilla.  It makes it appear that their web servers are down, when
they're actually available all the time due to clever fail-over and DNS-based
load balancing.

Comment 1

[Jo Hermans]

Dupe of bug 162871. See also bug 151929 comment 7 : the 'pinning' is the result
of some security fix a while ago.

Comment 2

[Jo Hermans]

Oop, I misread. This was split off bug 162871 ofcourse.

BTW : my daytime job is for a for telecommunciations manufacturer (I'm the
developer of one the largest access servers in the world). Our software also
shows this 'pinning' behaviour for a very good reason : security. We monitor
remote clients and servers continuously for any change. We're not even fully
respecting the TTL, we'll query the real DNS-server at least once an hour just
to be sure if we can catch any change in address (TTL is basically useless if
it's too large).

But the difference is that we're *not* going to switch to the new ip-address
directly. We could easily have a DNS-server that was hijacked (already
happened), or that was misconfigured (happens even more :-). No, if the
ip-address is changed, we'll warn the operators to double-check if the change is
allowed (the remote address is controlled by a another network provider).

I agree that we have a problem with load-balancing webservers and webserver with
multiple addresses. We really should try all existing ip-addresses before
deciding that a webserver is unreachable.

But when the ip-address of your webserver changes (when we fixed bug 151929), we
should *not* use the new address automatically. What we should do is to warn the
user that the ip-address is changed, and ask permission to continue. This should
especially happen when we're in the middle of a transaction !

Comment 3

[Sean Harding]

That behavior would cause a lot of user confusion. Most users don't even know
what DNS is; they will be annoyed to be prompted with warnings they don't
understand. When companies use products like Cisco DistributedDirector, DNS
information for a given hostname can change often. I really don't think we want
to pop an error or warning every time a user runs across this.

Comment 4

[Jo Hermans]

No, load balancing wouldn't be affected, you get only the warning when a
DNS-lookup changes to a completely different address, most likely because it
dynamic DNS address. A name that maps to 2 or more ip-addresses (poor-man load
balancing) won't trigger such a dialog. A hardware ip-switch hides several
servers behind 1 static ip-address - that won't change. A redirector that uses
regualar http-redirects to implement load-balancing (like used by Hotmail) won't
be affected.

If you really hate these dialogs to pop up, then I guess you want to remove
those security popups that occur on https-sites too (untrusted certificate, etc...).

I only want an extra dialog-box to warn me when an ip-address changes, so we can
avoid the Princeton exploit (see bug 149943), while avoiding the security
problem I see almost every week in my daytime job. The black-hat community is
really using these exploit to attacks access-servers all over the Internet.
Holding an ip-address in memory forever is a security problem, but allowing it
to be transparently changed is a security problem too! 

Comment 5

[Sean Harding]

DistributedDirectors can and do change the IP address returned for a given
hostname on a regular basis (with a short TTL on the A record). That is one of
their features, and people do use it. It WILL cause your proposed dialog to be
triggered under normal circumstances. 

If the SSL cert matches, you're fine (or you have bigger problems). If you're
not using SSL, you have no assurance that you're talking to who you think you're
talking to anyway. There's no security to begin with when you're relying on DNS
alone.

Comment 6

[Alan Eliasen]

This problem manifests itself at http://www.techtv.com/ which sends rather
short-lived TTL information for its A record.  After going for food and trying
to reload a page, I got "could not connect to server" errors.  From
packet-sniffing my connection, I could see that Mozilla was trying to use an
incorrect IP address that did not match authoritative DNS data.  Other browsers
worked fine.

Restarting Mozilla fixed the problem.

Comment 7

[Alan Eliasen]

This bug also occured today on the extremely popular sites
http://www.amazon.com/ and http://us.imdb.com/

These sites use Coyote Systems Equalizer which tends to hand out DNS records
with a TTL of about 60 seconds.  Verified via packet sniffer that Mozilla was
not sending to the authoritative IP address as returned by DNS.  Repeatedly got
"could not connect to server" error.  Other browsers were able to connect.

Comment 8

[Alan Eliasen]

I'm curious as to how the current security "fix" improves matters any.  If the
DNS record is already compromised when you start up Mozilla, then this will
"pin" to the compromised address for the whole time Mozilla is running.  If the
DNS server gets "uncompromised," you'll be pinned to the evil server and never
pick up the right one! 

There is no reason to believe that the address returned at whatever random
moment you first did a DNS lookup of a site is secure and other subsequent times
would be more insecure.  The "security fix" seems valueless, as it is based on
flawed assumptions.

The timing is completely random, based on the time you start Mozilla.  This is
the worst type of "security fix," one that not only leads to a false sense of
security, but is simply unable to improve security, and a violation of
standards, and opens other, more common security holes and usability problems
that don't require evil intent.  The "security fix" should simply be removed as
its benefit is purely illusory.

Comment 9

[Anthony DeRobertis]

Re: Comment #8.

You've mis-understood the problem pinning fixes. The problem is this: Let's say
that I, an evil attacker at www.evil.com, want to connect to a host behind your
firewall. Well, my problem is that darn firewall blocking me.

One day, I notice that JavaScript could be used to do it, except that JavaScript
can only make connections to the host it was downloaded from. So, being the Evil
Attacker that I am, I wonder "what exactly is defined as the 'same host'?" I
find out that it is a DNS based definition, so same host means 'same hostname'.
I then realize that I could set up an evil DNS server, with the following
behavior: On the first hit from your IP address, it returns 208.225.90.120, my
Evil IP Address; on the second hit, it returns 192.168.1.1, the
behind-the-firewall IP I want to attack.

So, here's what happens:
   1) You visit www.evilporn.com (or whatever)
   1(a) The IP address is 208.225.90.120
   2) You download some javascript from www.evilporn.com. This javascript
      sets itself up to do some stuff after the TTL on www.evilporn.com
      expires.
   3) The JavaScript timer fires. It attempts to access 'www.evilporn.com'
   4) Security policies see that javascript is trying to access its own
      server, which is OK.
   5) you resolve www.evilporn.com
   5(a) The IP address is 192.168.1.1
   6) Javascript hacks your host 192.168.1.1.

Pinning stops 5(a) by making the IP address still be 208.225.90.120, so I wind
up attacking myself.

Comment 10

[Todd Mokros]

How about, when a page is retrieved, the hostname/ip address of where that page
was retrieved from is cached with that page, and any javascript on that page
will always use that cached ip address for any 'same host' communication.  

I've been bit by this a couple of times, just recently with sourceforge when
they changed to a new IP.

Comment 11

[Account Deleted]

How does pinning of hostname->address help security anyway?

I guess that (please correct me if I'm wrong) JavaScript in a document from host
www.evil.com can not only access the DOM of documents from the same host, but
also from evil.com. If that is true, slightly modifying the attack that led to
the implementation of pinning would render that countermeasure completely
useless (leaving only its ugly side-effects):

In the DNS, attacker has:

www.evil.com A 1.0.0.1 ; address in the attacker's network
evil.com     A 10.0.0.1 ; some address in the internal network of $victim

Now, when $victim loads <URL:http://www.evil.com/>, a JavaScript on that page
could (if my assumption is correct) access evil.com, which is a host on
$victim's network. No changes of IP-addresses involved, hence pinning won't
defeat this attack.

Comment 12

[Boris Zbarsky [:bzbarsky]]

> please correct me if I'm wrong

You are wrong.  www.evil.com and evil.com are totally distinct for security
purposes; the only way for one to access the other is if they both set
document.domain to evil.com.

Comment 13

[Account Deleted]

>> please correct me if I'm wrong

> You are wrong.  www.evil.com and evil.com are totally distinct
> for security purposes; the only way for one to access the other
> is if they both set document.domain to evil.com.

I am sorry, I need to insist. According to the documentation at
<URL:http://www.mozilla.org/projects/security/components/same-origin.html>, in
my example, the attacker on http://www.evil.com could legally set
document.domain="evil.com"; making his evil pages' equivalent origin the *same*
as the origin of the $victim's internal server at http://evil.com, eventually
allowing him access.

I hope I'm not still mistaken with this extended description.

Thank you for replying during your vacation, btw.

Comment 14

[Daniel Veditz [:dveditz]]

Boris is right, both pages have to set document.domain="evil.com" explicitly
(even if that's the implicit value for one of the sites) in order to prevent
just the attack you propose. This was not always the case and old documentation
may not have caught up. IE 6.0 SP1 reportedly also made the change to require
both pages to have set document.domain explicitly. That's a completely different
problem so please don't drag it into the discussion on DNS pinning.

Comment 15

[Jo Hermans]

*** Bug 205148 has been marked as a duplicate of this bug. ***

Comment 16

[Mitchell Stoltz (not reading bugmail)]

->darin

Comment 17

[Jo Hermans]

Note that the patch in bug 205726 (nsDnsService rewrite) contains a preference
to disable DNS pinning (default remains enabled).

Comment 18

[Darin Fisher]

ok, now that the patch for bug 205726 has landed, DNS pinning is now a think of
the past.  this bug is fixed (note: on the trunk only).

Comment 19

[benc]

V fixed.