* [9fans] dns exploits (self-promotion remix) [not found] <261342.6156.qm@web27004.mail.ukl.yahoo.com> @ 2008-07-27 13:18 ` erik quanstrom 2008-07-27 15:56 ` Russ Cox 0 siblings, 1 reply; 11+ messages in thread From: erik quanstrom @ 2008-07-27 13:18 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] dns exploits (self-promotion remix) 2008-07-27 13:18 ` [9fans] dns exploits (self-promotion remix) erik quanstrom @ 2008-07-27 15:56 ` Russ Cox 2008-07-27 15:57 ` erik quanstrom 2008-07-27 22:22 ` don bailey 0 siblings, 2 replies; 11+ messages in thread From: Russ Cox @ 2008-07-27 15:56 UTC (permalink / raw) To: 9fans >> 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] dns exploits (self-promotion remix) 2008-07-27 15:56 ` Russ Cox @ 2008-07-27 15:57 ` erik quanstrom 2008-07-27 16:19 ` Russ Cox 2008-07-27 22:22 ` don bailey 1 sibling, 1 reply; 11+ messages in thread From: erik quanstrom @ 2008-07-27 15:57 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] dns exploits (self-promotion remix) 2008-07-27 15:57 ` erik quanstrom @ 2008-07-27 16:19 ` Russ Cox 2008-07-27 22:20 ` don bailey 0 siblings, 1 reply; 11+ messages in thread From: Russ Cox @ 2008-07-27 16:19 UTC (permalink / raw) To: 9fans >> 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] dns exploits (self-promotion remix) 2008-07-27 16:19 ` Russ Cox @ 2008-07-27 22:20 ` don bailey 2008-07-28 1:16 ` erik quanstrom 0 siblings, 1 reply; 11+ messages in thread From: don bailey @ 2008-07-27 22:20 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] dns exploits (self-promotion remix) 2008-07-27 22:20 ` don bailey @ 2008-07-28 1:16 ` erik quanstrom 2008-07-28 2:53 ` a 2008-07-28 2:57 ` don bailey 0 siblings, 2 replies; 11+ messages in thread From: erik quanstrom @ 2008-07-28 1:16 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] dns exploits (self-promotion remix) 2008-07-28 1:16 ` erik quanstrom @ 2008-07-28 2:53 ` a 2008-07-28 2:57 ` don bailey 1 sibling, 0 replies; 11+ messages in thread From: a @ 2008-07-28 2:53 UTC (permalink / raw) To: 9fans // 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] dns exploits (self-promotion remix) 2008-07-28 1:16 ` erik quanstrom 2008-07-28 2:53 ` a @ 2008-07-28 2:57 ` don bailey 2008-07-28 3:48 ` erik quanstrom 1 sibling, 1 reply; 11+ messages in thread From: don bailey @ 2008-07-28 2:57 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] dns exploits (self-promotion remix) 2008-07-28 2:57 ` don bailey @ 2008-07-28 3:48 ` erik quanstrom 2008-07-28 20:53 ` Wes Kussmaul 0 siblings, 1 reply; 11+ messages in thread From: erik quanstrom @ 2008-07-28 3:48 UTC (permalink / raw) To: 9fans > > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] dns exploits (self-promotion remix) 2008-07-28 3:48 ` erik quanstrom @ 2008-07-28 20:53 ` Wes Kussmaul 0 siblings, 0 replies; 11+ messages in thread From: Wes Kussmaul @ 2008-07-28 20:53 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] dns exploits (self-promotion remix) 2008-07-27 15:56 ` Russ Cox 2008-07-27 15:57 ` erik quanstrom @ 2008-07-27 22:22 ` don bailey 1 sibling, 0 replies; 11+ messages in thread From: don bailey @ 2008-07-27 22:22 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > if you're running ndb/dns -r, you need to build and boot a > new kernel to get the full 30 bits. > Bing! ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2008-07-28 20:53 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <261342.6156.qm@web27004.mail.ukl.yahoo.com> 2008-07-27 13:18 ` [9fans] dns exploits (self-promotion remix) erik quanstrom 2008-07-27 15:56 ` Russ Cox 2008-07-27 15:57 ` erik quanstrom 2008-07-27 16:19 ` Russ Cox 2008-07-27 22:20 ` don bailey 2008-07-28 1:16 ` erik quanstrom 2008-07-28 2:53 ` a 2008-07-28 2:57 ` don bailey 2008-07-28 3:48 ` erik quanstrom 2008-07-28 20:53 ` Wes Kussmaul 2008-07-27 22:22 ` don bailey
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).