Re: [9fans] dns exploits (self-promotion remix)

["Russ Cox" <rsc@swtch.com>]

>> i'm not a dns user (just the client side) on Plan9,
>> is the server part vulnerable to the recent poisonning attacks?
>
> i think the recent dns cache-poisoning vulnerability
> is more self promotion than substance.

i agreed until i saw the supposed exploit details that were
published last week.

it's the real deal, and if you're running a shared recursive dns
resolver that doesn't use both randomized query ids
and randomized source ports with proper demultiplexing
of requests, you're exposing your users to pretty trivial
dns hijacking.

kaminsky's short summary (http://www.doxpara.com):

    Before the attack:  A bad guy has a one in sixty five thousand
    chance of stealing your Internet connection, but he can only
    try once every couple of hours.

    After the attack:  A bad guy has a one in sixty five thousand
    chance of stealing your Internet connection, and he can try a
    couple thousand times a second.

    After the patch: A bad guy has a one in a couple hundred million,
    or even a couple billion chance of stealing your Internet
    connection.  He can still try to do so a couple thousand times
    a second, but it’s going to make a lot of noise.

(this isn't just bluster; it agrees with the technical details
already suggested by others.)

and that's just the supposed details.  kaminsky's blog
would suggest that he's got more tricks up his sleeve
than people have figured out yet.  even if that's not true,
what people have figured out already is bad enough.

> my friends at [dns operator] agree.

if you're a dns operator in the sense of just serving your
own results (like the dns servers for bell-labs.com just
answer questions about bell-labs.com from a text file),
then you don't need to worry about this.

but if you're a dns operator in the sense of providing
a general dns resolution service to clients, it's a big
mistake to think this isn't a big deal.  if your friends
fall in the latter category, you should talk to them again.

the exploit targets a common dns client design flaw,
by making requests to a recursive dns server, like the
servers that your isp gives out in its dhcp replies.
i mean isp considered broadly: corporate networks,
schools, and so on.  if there is a recursive dns resolver
that a single malicious user can query, all the other
users of that resolver stand to get incorrect dns information.

> however, ndb/dns does use randomized query ids.
> you can use snoopy to verify this or you can read
> the source.  (ndb/dnresolv.c/^queryns) so it is not
> vulnerable.

this alone is not enough, because the query id
only supplies 15 bits of randomness.  luckily, ndb/dns
already created a new udp source port for each
request, using the kernel for proper demultiplexing,
mainly because it was simpler:

    /*
     * in principle we could use a single descriptor for a udp port
     * to send all queries and receive all the answers to them,
     * but we'd have to sort out the answers by dns-query id.
     */

that leaves choosing random source ports.  ndb/dns
leaves the choice up to the kernel (as most programs do).
we put code into /sys/src/9/port/devip.c on july 15
to allocate source ports randomly rather than sequentially.

those things combined mean that you get 15 bits of randomness
from query id and 15 from source port, giving 30 bits,
so ndb/dns is okay (for now).

if you're running ndb/dns -r, you need to build and boot a
new kernel to get the full 30 bits.

russ