Re: The State of the DNS and Tor Union (also: a DNS UDP - >TCP shim)

[Jacob Appelbaum <jacob@xxxxxxxxxxxxx>]

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 <jacob@xxxxxxxxxxxxx> 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 resolve a random site or hidden service
> immediately and attempt to connect, but this attempt (via transparent
> transport access) may hang indefinitely for minutes before success or
> failure.  some prefer to have more explicit control over these
> resolution timers and timeouts.
> 

Understood.

> 
> 
>> ===================== A New Hope: ttdnsd ===============================
>> ...
> 
> coming soon: <clever play on star wars idiom>
> 
> 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.

> - dnsport transparent resolve through Tor

This is of course useful.

> - ttdnsd based tunneled TCP DNS from exit

Of course.

> - host based interception and/or filtering mechanisms against side
> channels around the above
> 

I believe that this is the job of something like unbound or pdnsd;
though it may be the case that adding an RFC1918 filter into ttdnsd
would be useful.

> until then you're exposing yourself to specific attacks and providing
> poor end user experience in other situations.

I'm not entirely sure. Part of the interesting issue here is about DNS
queries and using Tor with those queries. For example, if I want to know
that foo.bar.com resolves to 10.0.0.1 - there is nothing dangerous about
that. ttdnsd will do the right thing, Tor will anonymize my query, and
all is well.

You are very correct to point out that this may be an issue if a browser
were to use that, it may be possible to attack the local network. I
think that only transparent proxying will really solve this this - what
do you think?

> 
>> ========================= Caching Answers ==============================
>> ...
> 
> a discussion of negative caching might be useful. some people
> encounter situations where they get a positive responsive from an
> explicit request but host based resolver facilities still return not
> found. see also host based caches like nscd.
> 

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.

> 
>> ==================== Additional Privacy Issues =========================
>>
>> Some applications may provide a proxy setting but disregard it in
>> certain circumstances. ttdnsd can make the use of these applications
>> safer with regard to DNS leaks.
> 
> not really. this is the exception rather than the rule, or even common case.  :(
> 

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.

I checked a recent XMPP client and found that it now does the right
thing with regard to SRV records. I was very surprised.

All the best,
Jake
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/