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

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

[erik quanstrom]

> 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.  my friends
at [dns operator] agree.

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.

the other part of this promotion was selling dnssec.
i'm not sold.  see the five objections to dnssec in
the second paragraph.
http://en.wikipedia.org/wiki/DNSSEC

next up, the exploit remix.

- erik

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

[Russ Cox]

>> 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

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

[erik quanstrom]

> 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).

why only 15 in the query id?  that's an artifact of rand()
which returns 0 ≤ n ≤ 0x7fff.  why not return numbers
between 0 and 0xffff?

- erik

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

[Russ Cox]

>> 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).
>
> why only 15 in the query id?  that's an artifact of rand()
> which returns 0 ≤ n ≤ 0x7fff.  why not return numbers
> between 0 and 0xffff?

one might change rand or dns to get 16 bits, and that'd be fine.
i doubt many programs depend on rand not returning
numbers bigger than 32767.  or you could use fastrand()&0xffff
in dns, which would be even better.

it's just one bit though.  getting the other 15 was more important.

russ

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

[don bailey]

The exploit doesn't simply rely on the 16bit dns XID.
Rather, it's reliant on the fact that bind servers
(and some others) send requests from a static port.
Obviously, if you control a DNS server or you can
sniff the target DNS server's path, you can figure
this out.

The second part to the trick is wildcarding in DNS.
I can make a large number of invalid queries to your
DNS server if it allows recursing. Each query will
be something like aaa.paypal.com, bbb.paypal.com, etc.
Obviously, because I know your source port (or can
figure it out) it's only a matter of time before I
can spoof a response. So, you'll end up with a wacky
A entry for somerand.paypal.com. The neat trick here
is that I can also attach a NS record in the spoofed
response and set the TTL very high for this entry.
Now your DNS server will query my malicious DNS server
for everything under paypal.com.

So, yes, plan9 is vulnerable.

D

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

[erik quanstrom]

> The exploit doesn't simply rely on the 16bit dns XID.
> Rather, it's reliant on the fact that bind servers
> (and some others) send requests from a static port.
> Obviously, if you control a DNS server or you can
> sniff the target DNS server's path, you can figure
> this out.
>
> The second part to the trick is wildcarding in DNS.
> I can make a large number of invalid queries to your
> DNS server if it allows recursing. Each query will
> be something like aaa.paypal.com, bbb.paypal.com, etc.
> Obviously, because I know your source port (or can
> figure it out) it's only a matter of time before I
> can spoof a response. So, you'll end up with a wacky
> A entry for somerand.paypal.com. The neat trick here
> is that I can also attach a NS record in the spoofed
> response and set the TTL very high for this entry.
> Now your DNS server will query my malicious DNS server
> for everything under paypal.com.
>
> So, yes, plan9 is vulnerable.

i don't understand this
1.  plan 9 never used a static source port for queries,
and more importantly

2.  who does recursive queries on external interfaces?
i would have considerd this a configuration error and
security problem ten years ago.

- erik

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

[a]

// 1.  plan 9 never used a static source port for queries,

Using dynamic ports is better than static, but if they're
sequential (or otherwise predictable), it doesn't buy you
all that much.

// 2.  who does recursive queries on external interfaces?

I've been traveling in companies and countries with
restricted local DNSs, but open routes to home. Or open
enough to get DNS through; sometimes not VPN, ssh, or
functional equivalent (to say nothing of 9p). Being able
to query an unrestricted DNS was wonderful.

I've also worked for companies who had folks working from
home pointing their home computers at work DNS (and some
other services) over the public internet. I'd probably
grant that it's a security problem, but it wasn't an
"error" in the normal sense.

Anthony

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

[don bailey]

> i don't understand this
> 1.  plan 9 never used a static source port for queries,
> and more importantly
>

Erm, sequential source ports are close enough.

> 2.  who does recursive queries on external interfaces?
> i would have considerd this a configuration error and
> security problem ten years ago.
>

Tell that to the rest of the internet. It's not that
simple, either. I am using recursive capability as an
example of making an attack extremely easy. I could
also send you an e-mail with HTML that loads images
from a specific domain name. There are a million other
vectors that are just as predictable because of the
luxury of web2.0. Recursive queries obviously just
make this simpler for the attacker.

D

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

[erik quanstrom]

> > 2.  who does recursive queries on external interfaces?
> > i would have considerd this a configuration error and
> > security problem ten years ago.
> >
>
> Tell that to the rest of the internet.

without reasonable configuration, most any machine can
be made trivially vulnerable.

> vectors that are just as predictable because of the
> luxury of web2.0. Recursive queries obviously just
> make this simpler for the attacker.

what is this "web 2.0" of which you speak?  i use
plan 9 and unfamilar with such as i presume to be jargon.  ☺

to do it from the inside, one requires out-of-balliwick
hints to be cached, right?  this should be a big hurdle.

it's dissapointing to note that plan 9 dns does no hint
validation.  that is perhaps a larger long-known, and
still-exploitable hole than the one that gets so much press.

i think it would be best if ndb/dns simply did not reply
with answers obtained from glue but rather re-queried
the authorative ns *and* rejected out-of-balliwick
hints.

- erik

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

[Wes Kussmaul]

erik quanstrom wrote:

> what is this "web 2.0" of which you speak?

Web 2.0, n. A space created by artists who got all excited when they
heard the word "sandbox," not realizing it meant the opposite of what
they thought.

wk

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

[don bailey]

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

Bing!