On Mon, Jul 5, 2010 at 6:49 PM, Jacob Appelbaum <[email protected]> wrote: > ... > Nice catch. Do you want to provide some test cases for this? I guess it > would be nice to see how wide-spread this problem is - it would also > help us build in some protection mechanisms.
to manually test: 1. route -n or equiv to find default gateway (running dproxy-nexgen or equiv. DNS proxy / resolver) (for remainder of this sequence 192.168.1.1 is assumed to be router and dproxy host) 2. dig @192.168.1.1 192.168.1.1 3. observe the ISP provided hostname in answer 4. dig @192.168.1.1 <ISP hostname> 5. observe public IP endpoint address in answer not sure how many routers run this kind of stuff, but they number in the millions. (cheap Linux routers, Wifi captive portals, etc.) as for Java test case, i can dig up the applet code from ages back, if i've got it. i recall another avenue via sun.net.spi.nameservice.provider and sun.net.spi.nameservice.nameservers. there is also a mechanism via JNI to use _res.options global to reset DNS bindings, and open up other attacks. (although if you've got JNI access these are all less interesting approaches.) >>> Having a local DNS server is useful; many applications may only support >>> SOCKS4, rather than SOCKS4A or SOCKS5 - their failure could lead to >>> de-anonymization. It is also useful to ensure that possible DNS leaks >>> will fail closed - if your system only knows about 127.0.0.1:53, it's >>> hard but not impossible to leak DNS packets to the public internet. >> >> not really hard in any sense of the word. :( >> > > Can you give me an example of how you'd do this? I know that if a user > does something like `dig @8.8.8.8 torproject.org` - the query won't go > to 127.0.0.1:50 - But if you can do that, you've already won in a very > serious way consider the case of a link local resolver like above, or any DNS server on the LAN for public routed requests. you don't need arbitrary execution; i agree that's game over in any case. > I haven't seen a PERL version of the program - do you have a link to the > source? I noticed a newish python version was written by Dug Song. I > think it's similar in scope to ttdnsd. yeah, not to be confused with the dsocks python version. i'll find a copy and forward it on. i know it's around here somewhere... >> the best of all worlds would combine: >> - virtualaddrnetwork based immediate resolve and map > > I'm not sure that this is too useful because of the issues with OpenSSH; > I'd prefer that it simply fail. right, i usually don't like this behavior. but sometimes it is very handy, particularly when applications cache negative responses for too long, or aggressive DNS rebinding attack prevention makes a resolution last much longer than you'd like. (in which case, in is better to be stuck to a binding against 10.x or other virtualnetwork addr that can reconnect on the TCP side rather than having an old public DNS mapping that persists beyond TTL, etc.) this is all a bit technical, and i agree that the above is the lesser desired behavior. > ... > Can you give me an example of that happening with ttdnsd? I'm not sure > that I've ever encountered it with Tor; generally I find negative > caching issues like that one to be a bug. i'm thinking of the Windows DNS cache behavior. it probably should be considered a bug :) > It sounds like you have some great stuff up your sleeve; you should help > hunt the DNS de-anonymization unicorns. :-) > > If a user's local DNS resolver is 127.0.0.1 (via ttdnsd), a user will > not be able to leak information as easily as it will with a network or > non-Torifed resolver. agreed. the issue is when you've got a link-local resolver accessible, and a mechanism to perform DNS queries against it. in such a case, the host configuration of 127.0.0.1 is simply ignored, and an explicit local resolver is queried. *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/
