Re: The State of the DNS and Tor Union (also: a DNS UDP - TCP shim)
On Sun, Jul 4, 2010 at 3:17 PM, coderman coder...@gmail.com wrote: ... a better wording: ... ultimately, any application that uses DNS or UDP may compromise your anonymity. i should mention that the Tor Browser Bundle when used as directed has been and continues to be most resilient to these attacks. while this is a very limited environment (no plug-ins, flash, java, etc.) these limitations are a feature ensuring your protection. when you start using arbitrary applications or plug-ins with Tor or any other anonymity service you open yourself up to great risk as described here for DNS, not to mention other side channels avenues using TCP directly. best regards, (hi pedants!) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: The State of the DNS and Tor Union (also: a DNS UDP - TCP shim)
On 07/04/2010 03:17 PM, coderman wrote: great info! my comments below... On Fri, Jul 2, 2010 at 6:15 PM, Jacob Appelbaum ja...@appelbaum.net wrote: ... While Tor users should always use Torbutton[-1] for their web browsing, not all applications have an equivalent plugin available. Torbutton addresses DNS leaks from within Firefox by ensuring that Firefox uses the local Tor proxy for its DNS name lookup requests. However, other applications may not do this and may, as a result, leak DNS requests. We try to discover if popular applications are leaky but, ultimately, any application that makes a DNS request may compromise your anonymity unless specifically configured to make that request over Tor. The central concern is thus for an applications that don't know to send their name lookup requests via Tor, or don't know how to do so. Tor can't protect these applications' requests. a better wording: ... ultimately, any application that uses DNS or UDP may compromise your anonymity. best intentions fail in the face of an attacker in most circumstances. Java can be configured to use explicit resolver endpoints regardless of suggested default proxy or other configuration. raw UDP sockets via third party plug-ins are worst case. note that even with transparent proxy configuration and DNS port you are at risk if the attacker can direct explicit DNS requests to a local resolver (over link-local route, not default gateway). this type of attack affects all VPN or transparent proxy configurations that do not use a /29 point-to-point router path. to add insult to injury, many commercial Linux based routers like ActionTek and D-Link use dproxy-nexgen resolvers accessible at link-local 192.168.1.1. a reverse lookup of the gateway itself provides not just the internal address but also the public IP and hostname from ISP. there are other caching resolvers used in captive wifi portals and other locations with same behavior. 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. ... 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. I'd argue that you have arbitrary code execution and that if that is the threat, you'd simply need to hook ttdnsd as part of a transparent proxying setup. This was part of the original design of ttdnsd and it seems like that solves the leaking DNS issue entirely. === Old Hope: tor-proxy-dns ... Once, a long time ago, we had a super star programmer named Tup in our community. He was anonymous to us. He was a programming machine and we really miss him. We often wonder and worry about what has happened to our friend. He would crank out code in a myriad of languages that served all sorts of useful purposes. One of the things that he wrote was a small program in Python called tor-proxy-dns; this software was useful but written in Python, abandoned by the missing superstar, and generally lost to the sands of time. PERL, but that doesn't detract from the awesome that is Tup. Ah darn. Thank you for the correction. 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. sadly, we are not currently temporally propinquitous with Tup. I miss Tup and wish he would return. :-( VirtualAddrNetwork is an obscure but very useful option for decreasing latency at connection time. When enabled, Tor will automatically return a specially mapped IP address. Eventually, Tor will learn the real address and keep an internal mapping between the virtual address and the real address. Tor remembers this mapping for the duration of execution but it is not saved between Tor restarts. This works except in cases where the IP address is noted by an application, such as OpenSSH. This will decrease perceived and actual latency but it has frustrating side effects for some applications. the other trade-off with this approach is that is behaves very poorly with some applications that expect name resolution to fail on un-reachability (like .onion or .exit) rather than in-determinate connection establishment. A good point. I'll add that. that is, your application may
Re: The State of the DNS and Tor Union (also: a DNS UDP - TCP shim)
On 07/05/2010 03:07 PM, coderman wrote: On Sun, Jul 4, 2010 at 3:17 PM, coderman coder...@gmail.com wrote: ... a better wording: ... ultimately, any application that uses DNS or UDP may compromise your anonymity. i should mention that the Tor Browser Bundle when used as directed has been and continues to be most resilient to these attacks. while this is a very limited environment (no plug-ins, flash, java, etc.) these limitations are a feature ensuring your protection. I think that the TBB could use one and only one major enhancement: a DNS proxy that is used by all of the applications that ship with it. when you start using arbitrary applications or plug-ins with Tor or any other anonymity service you open yourself up to great risk as described here for DNS, not to mention other side channels avenues using TCP directly. I agree. I think that this is inspiring me to work on torwall a little more next week... All the best, Jake *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: The State of the DNS and Tor Union (also: a DNS UDP - TCP shim)
On Mon, Jul 5, 2010 at 6:49 PM, Jacob Appelbaum ja...@appelbaum.net 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 majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
