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

[coderman <coderman@xxxxxxxxx>]

On Mon, Jul 5, 2010 at 6:49 PM, Jacob Appelbaum <jacob@xxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/