Re: distributed.net and seti@home

[OFriedrichs () SECURITY-FOCUS COM (Oliver Friedrichs)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> > DNS cache corruption will be possible until DNS-SEC is in wide
> > use.
>
> Yes, but I can think of a non-DNS-SEC nameserver which is
> configured in a way that will render DNS spoofing nearly
> impossible, that is
>
>   a) only allowing queries from your internal IP range
>   b) anti spoofing rules active on your border routers
>   c) no other nameservers within your network
>   d) querying multiple external nameservers for a domain, randomly
>      select three or four from a list of several thousands,
> then comparing
>      all the answers
>   e) only accepting one id per answer, dropping every answer after
> one
>      invalid id, hence rendering a dns id spoofing attack
> near to impossible
>   f) accepting only one query for a domain within a given
> timeframe,
>      eg. one minute

Agreed, this would go a long way towards protecting you.  Obviously
you still can't control the servers outside of your domain - but
querying multiple would help verify the data.  Unfortunately, this
and (f) are impractical.  DNS is slow enough as it is.  (f) is
completely out of the question.  What you need to do here is build a
queue of hosts which have asked for the same query, and when you
receive the reply yourself, send each host an answer.  This only
makes sense, why duplicate your efforts each time?  I really don't
know why BIND doesn't do this.  Theo de Raadt once told me that BIND
is such a mess that it's not easy to do this.

One of the things which also protects you against ID prediction (more
so than a random ID), is random source ports for each query.  I
believe that BIND does this now.  I recall someone mentioning
problems configuring their network, as BIND was no longer using
source port 53.  This causes other nightmares, but it goes a long way
to prevent spoofing.

> > I haven't seen any tools using the parallel query attack to
> > poison the cache however (yet).  Randomizing the query ID does
> > little to
>
> This is not necessary. Instead of sending out 100 queries you
> can just send out 100 answers.

This doesn't actually create the same result.  Take the following
scenario, assuming the IDs are generated in a random fashion, across
the entire ID space, guaranteeing that previous ID's are not reused
for a period of time (like OpenBSD IDs).

- - Send 1000 answers

We send 1 query, the nameserver creates query with a random ID, lets
say it's 32123.

We send 1000 answers.. where do we start?  We really don't have a
starting point, knowing that the ID's are random.  We can use an ID
we got from a recursive query to ourselves, but thats not going to be
near 32123 if it's random at all.

- - Send 1000 queries + 1000 answers

We send 1000 queries, the nameserver creates 1000 queries, with
random IDs across the ID space.  Now assuming the law of averages,
and a perfect world, we essentially have 1000 IDs, each about 655
apart.  In reality this will obviously vary.

We send 1000 answers.  We can potentially poke anywhere in our ID
space, starting even at 0, and have a higher probability of getting
one right, than if we only sent 1 query to begin with.

The solution: Fix BIND to not duplicate requests.  It really can't be
that hard, this problem has been known for years.  Its even been in
commercial security scanners for years.

Oliver Friedrichs
securityfocus.com

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>

iQA/AwUBOJh37cm4FXxxREdXEQJZ5ACgoLhkjRI4UDRvUslrrFp8SXW2pWoAoJsK
b8HEC0fIVPxmtAvzlxQFV1Dt
=1sxP
-----END PGP SIGNATURE-----