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

This is a discussion on [9fans] dns exploits (self-promotion remix) - Plan9 ; > 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] ...

+ Reply to Thread
Results 1 to 11 of 11

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

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

    > 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



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

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



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

    > 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



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

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



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

    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



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

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


    Bing!



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

    > 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



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

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


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

    > 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



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

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



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

    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




+ Reply to Thread