[tor-dev] InjectSOCKS: 2nd try

tor at herr-der-mails.de tor at herr-der-mails.de
Tue Dec 17 15:05:29 UTC 2013

Hello David,

> Yes, UDP is simply not supported by Tor thus it will be rejected
> when opening the socket. Actually, it's not only UDP that should be
> blocked but *every* other protocol except TCP. For instance, there
> is no way to send icmp request through Tor thus we don't want that
> to leak.
> This is dangerous and the reason why it's denied is that the
> application  could easily make a DNS request for instance to a
> local server that will then resolve it on a remote one thus
> leaking.
> You should really reconsider that, going locally can be fine but
> also really dangerous.

Thanks for all the advice. I've uploaded a new version now where the 
default behavior is to block any other sockets than TCP sockets and 
to block 127.x.x.x traffic.
However, there is the optional switch /a to allow this as some 
software just needs it, e.g. Internet Explorer uses local UDP traffic 
to communicate between its processes. So the user can decide per 
process which mode to use.
The new version also has some additional tweaks and fixes.

Concerning the upper "security" feature I think that everybody using 
a software like InjectSOCKS should be aware that there are a lot of 
ways to bypass all this. You shouldn't rely on it. The goal of 
InjectSOCKS is to use software together with Tor (or other SOCKS 
servers) even if it doesn't support this. Creating a sandbox or 
disabling malware is not the goal of InjectSOCKS.
There are other tools for that and it's a good idea to have a 
firewall preventing any "bad" traffic.

Well, at least it's a proof of concept that you can manipulate the 
process behavior using this technique :-)

> I'll take a look at it and if I can find a Windows, test it.

If you just want to test it you could use the official Microsoft 
trial version running for 90 days or something like that.

> From that point on, I'll check how feasible it is to integrate what
> you did in the new torsocks code so we can have *nix and Windows
> support in the same tool, that would be quite awesome.

This sounds very interesting. My guess is that while the tools are 
similar, the internals are quite different. But this is just a guess 

Thanks for the effort.


More information about the tor-dev mailing list