From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@9fans.net Subject: Re: [9fans] dns exploits (self-promotion remix) From: "Russ Cox" Date: Sun, 27 Jul 2008 11:56:21 -0400 In-Reply-To: <7c6217a4006705fe32b6000c4d2d6c03@quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Message-Id: <20080727155414.5C8501E8C1C@holo.morphisms.net> Topicbox-Message-UUID: f27f3d10-ead3-11e9-9d60-3106f5b1d025 >> 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