headers
Don Marti | 24 Jul 18:38

Applications and the infamous DNS vulnerability

On a properly set up home or office network, it should
be difficult to poison the nameserver completely
from the outside -- for a long time it's been best
practice to put your public DNS on a separate machine.

Of course an attacker can easily trick an application
on the inside into doing a bunch of DNS queries --
the simplest example is that a user could visit a
malicious web page with a bunch of images.

Should applications that handle untrusted data
be keeping track of the number of times they get
NXDOMAIN for subdomains of one domain -- some kind
of wrapper around getaddrinfo -- then refusing to
query again if there are so many that it looks like
an attack?  Maybe with a "I'm not looking up another
randomcrap.example.com domain for you" dialog, or
maybe just stop processing the offending web page or
whatever other data source is causing the queries?

--

-- 
Don Marti                                               +1 415-734-7913 mobile
http://zgp.org/~dmarti/
dmarti <at> zgp.org         Linux device driver unconference: http://freedomhec.org/
Permalink | Reply |
headers
Matthew Galgoci | 24 Jul 19:38
Favicon

Re: Applications and the infamous DNS vulnerability

> Date: Thu, 24 Jul 2008 09:40:04 -0700
> From: Don Marti <dmarti <at> zgp.org>
> To: linux-elitists <linux-elitists <at> zgp.org>
> Subject: [linux-elitists] Applications and the infamous DNS vulnerability
>
> On a properly set up home or office network, it should
> be difficult to poison the nameserver completely
> from the outside -- for a long time it's been best
> practice to put your public DNS on a separate machine.
>
> Of course an attacker can easily trick an application
> on the inside into doing a bunch of DNS queries --
> the simplest example is that a user could visit a
> malicious web page with a bunch of images.

Or send a flood of spam with rfc1918 addresses in the headers
that you actually happen to use internally.

--

-- 
Matthew Galgoci
Network Operations
Red Hat, Inc
919.754.3700 x44155
Permalink | Reply |
headers
Rick Moen | 24 Jul 23:37
Favicon

Re: Applications and the infamous DNS vulnerability

Quoting Don Marti (dmarti <at> zgp.org):

> On a properly set up home or office network, it should
> be difficult to poison the nameserver completely
> from the outside -- for a long time it's been best
> practice to put your public DNS on a separate machine.

There are some benefits to doing so, but it does rather little to
prevent cache poisoning -- which can affect a variety of nameserver
hosts that do recursive-resolver service and then cache the results, 
even those that don't accept recursive queries from public networks.

So:  A recursive-resolver server that's on an IP different from your
"public" DNS is no less threatened.

Note that even the "stub resolver" built into Linux libc / glibc is
vulnerable to some deviltry on account of _its_ recursive queries
not originating in randomised source UDP ports but rather always coming
from port 53.  However, the results thereof don't get _cached_, so any 
poisoned information gets flushed right away.  (Running nscd would be
bad, in this context -- but then, it sucks, and if you use it at all
you should always disable its caching of DNS data on general principle.)

Absence of caching likewise mitigates the horrific vulnerability of
pretty nearly everyone's cheap SOHO router appliance.  Yes, they'll be
easy to hit with forged DNS RRs, but they're too anemic to spare the RAM
to, so to speak, refrigerate the poisoned meat.

OTOH, those same El Crappo appliances will also tend to de-randomise,
during NAT conversion, the outbound recursive queries from people's
(Continue reading)

Permalink | Reply |

Gmane