Re: [Whonix-devel] Circuit isolating proxy?

[Patrick Schleizer]

Keeping the full quote to share it on qubes-devel.

William Budington:
> Hey all,
>
> I'm using whonix from within Qubes. I'm trying to find a way to
> remove the tor ports as an attack surface from the whonix-ws while
> still maintaining circuit isolation for applications run within
> workstations. Currently, I see that the tor ports are forwarded from
> the whonix-gw via rinetd.
>
> Possible solution: a piece of software intended to be used on
> whonix-gw which opens one network interface per circuit, and
> provisions an arbitrary number of VMs with circuit-isolated,
> transparently torified connections without exposing the tor
> socks/control ports to them. That way you could run one application
> per VM which is on an isolated circuit, but has no access to the tor
> ports. Does anything like this currently exist?
>
> Obviously this would be a bad solution for the Tor Browser, which
> relies on access to the tor ports to do per-tab isolation. But I
> figure it would be an okay solution for other applications that do
> not rely on such hands-on circuit control.
>
> -Bill

Now my answers inside.

William Budington:
> Does anything like this currently exist?

tun2socks?

> I'm using whonix from within Qubes. I'm trying to find a way to
> remove the tor ports as an attack surface from the whonix-ws while
> still maintaining circuit isolation for applications run within
> workstations.

> Currently, I see that the tor ports are forwarded from
> the whonix-gw via rinetd.

re rinetd: Only those used by Tor Browser (and torchat). Other open Tor
ports on Whonix-Gateway (such as for HexChat) are under the current
implementation directly talked to.

(Not that it matters much for the sake of this subject: When you upgrade
Whonix-Workstation, anon-ws-disable-stacked-tor was migrated to socat.)

> Possible solution: a piece of software intended to be used on
> whonix-gw which opens one network interface per circuit,

It's an interesting idea.

So the application talks to a virtual network interface directly rather
than directly to a Tor SocksPort?

- Then this virtual network interface would eventually talk to a Tor
SocksPort?
- Okay, if I got that right, the application couldn't try to exploit a
bug in Tor's socks implementation. So the tun2socks application would
have to be more resistant against exploitation than Tor's socks code?

Eventually we use something like this [1] to configure specific
applications to specific virtual network interfaces?

> and
> provisions an arbitrary number of VMs with circuit-isolated,
> transparently torified connections without exposing the tor
> socks/control ports to them. That way you could run one application
> per VM which is on an isolated circuit, but has no access to the tor
> ports.

Hm. Alternatively it would be possible to configure Whonix-Gateway's
firewall to disallow any socksified traffic.

If you like to look into that:

whonix-gw Tempalte: /etc/whonix_firewall.d/50_user.conf or
sys-whonix: /rw/config/whonix_firewall.d/50_user.conf

WORKSTATION_ALLOW_SOCKSIFIED=0

(reload Whonix firewall 'sudo whonix_firewall' in sys-whonix or reboot)

[Of course also possible to make more fine tuned changes such as
disabling only specific SocksPorts...]

Disable stream isolation per application or globally, see [2]. I.e.
configure the application you want to use to use transparent
torification. [Which is the default, unless the application is
configured by Whonix default to use a Tor SocksPort. See list. [3].]

Multiple Whonix-Workstations using transparent proxying Qubes-Whonix are
already easily automatically stream isolated from each other because
they have a different client IP addresses and Tor default uses
IsolateClientAddr.

You'd end up with your application-A in a anon-whonix-one, that is using
transparent proxying and your application-B in anon-whonix-two.
anon-whonix-one and anon-whonix-two would be stream isolated
(IsolateClientAddr). Both stream isolated from each other. No Tor
SocksPort usage involved.

[Some thing would have to be sorted out such as sdwdate time
synchronization but I also have an idea here that I can specify if this
is of interest.]

It isn't the default implementation because in Qubes we are not so much
considering to run one VM per application, but one VM per security
domain (e.g., “work,” “personal,” “banking,” etc.) (multiple
applications per VM). And we wouldn't want to funnel all traffic from a
whole domain into the same Tor circuit.

> Obviously this would be a bad solution for the Tor Browser, which
> relies on access to the tor ports to do per-tab isolation.

(Tor Browser just talks to only a single Tor SocksPort. [And in the next
major version 6.5 it talks to a single unix domain socket.]) [Tor
Browser by tab isolates by (ab)using socks user auth.]

> But I
> figure it would be an okay solution for other applications that do
> not rely on such hands-on circuit control.

Certainly interesting to discover.

Best regards,
Patrick

[1]
http://superuser.com/questions/241178/how-to-use-different-network-interfaces-for-different-processes
[2] https://www.whonix.org/wiki/Stream_Isolation/Disable_Easy
[3] https://www.whonix.org/wiki/Stream_Isolation#List
[4] https://www.qubes-os.org/getting-started/

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, Dec 11, 2016 at 11:13:00PM +0000, Patrick Schleizer wrote:
> > Possible solution: a piece of software intended to be used on
> > whonix-gw which opens one network interface per circuit,
>
> It's an interesting idea.
>
> So the application talks to a virtual network interface directly rather
> than directly to a Tor SocksPort?
>
> - Then this virtual network interface would eventually talk to a Tor
> SocksPort?
> - Okay, if I got that right, the application couldn't try to exploit a
> bug in Tor's socks implementation. So the tun2socks application would
> have to be more resistant against exploitation than Tor's socks code?

I think it is *REALLY BAD* idea to add additional, hand-crafted IP
packet parser (tun2socks). Pretty much the same data will reach tor
socks anyway, but you'll add another attack surface of tun2socks.
Socks protocol isn't that complex to worth hiding behind such complex
thing like tun2socks. Socks is just a request packet ("where connect
to") followed by unmodified TCP stream. Tor needs to parse only that
initial request packet.

What is worth guarding, it tor control socket, and it isn't directly
exposed. There is "control-port-filter-python" (or something else in new
Whonix version?) to filter it. IMO it would be much better if control
port wouldn't be exposed at all, but unfortunately some applications do
require it.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYTeRJAAoJENuP0xzK19csDrAH/1KuaQ90ip4soQ1DyXZP0M01
uj9nZIM5uM+4g7zvb0/Vsu2DANxDXlCU35+6H43Zq7H1vQ83nUj9iBvJoHRy8PAF
3a86AaVID2/nhtrfVdcEsleH6wz3bGfumGQJJQqamyRf6Lr/tXc/dQtTCYNmnajS
IYyDz1COommbZ69u9gBx6xjbAPTqKj6kkS8z0eKfjfn2Xw+Oo8hRL6xGmvZ8Ziqe
hkNrZYSq9DKkuSJ0kD1Fp9aUySMDZkdpd56hK7uYbh7AOQxo11482L6bs+/YH403
qbUDHYHH+jeq6Rr9jv67uLm/qQUfewRHXULwiRNdHzpuHH/snsge5Srm/TE2LFE=
=HhTu
-----END PGP SIGNATURE-----

[Patrick Schleizer]

Marek Marczykowski-Górecki:

> On Sun, Dec 11, 2016 at 11:13:00PM +0000, Patrick Schleizer wrote:
> There is "control-port-filter-python" (or something else in new
> Whonix version?) to filter it.

control-port-filter-python python2.7 code has been replaced by
tor-controlport-filter by Tails (python3).

Reasons and changes are in this ticket:
https://phabricator.whonix.org/T573

Best regards,
Patrick

[William Budington]

I wasn't aware of the IsolateClientAddr option within tor. With the assurance that each source ip will be stream isolated, no `tun2socks` proxy or equivalent is necessary, given that whonix-ws is transparently torified. For applications that do not require direct tor port access, separating them into their own VM and modifying iptables rules on sys-whonix so that these VMs have no access to the tor ports should work for my intended purpose.

Since the browser is such a large attack surface, for whonix-ws VMs which only use Tor Browser, I wonder if access to the control port could be fully denied? It seems so. Since the Tor Launcher isn't actually bootstrapping tor, the control port is only used for the "New Identity" functionality, so you'll lose that. But if you kill the `socat` process forwarding 9151, the browser seems to work fine. It seems like the "New Identity" functionality could be implemented on the whonix-gw side: https://blog.torproject.org/category/tags/new-identity

Looks like the Tor Browser use of the control port isn't going away, though. And in fact may be increasing in the future: https://trac.torproject.org/projects/tor/ticket/9675

On Mon, 12 Dec 2016 00:42:02 +0100, Marek Marczykowski-Górecki wrote:
> On Sun, Dec 11, 2016 at 11:13:00PM +0000, Patrick Schleizer wrote:
> > > Possible solution: a piece of software intended to be used on
> > > whonix-gw which opens one network interface per circuit,
> >
> > It's an interesting idea.
> >
> > So the application talks to a virtual network interface directly rather
> > than directly to a Tor SocksPort?
> >
> > - Then this virtual network interface would eventually talk to a Tor
> > SocksPort?
> > - Okay, if I got that right, the application couldn't try to exploit a
> > bug in Tor's socks implementation. So the tun2socks application would
> > have to be more resistant against exploitation than Tor's socks code?
>
> I think it is *REALLY BAD* idea to add additional, hand-crafted IP
> packet parser (tun2socks). Pretty much the same data will reach tor
> socks anyway, but you'll add another attack surface of tun2socks.
> Socks protocol isn't that complex to worth hiding behind such complex
> thing like tun2socks. Socks is just a request packet ("where connect
> to") followed by unmodified TCP stream. Tor needs to parse only that
> initial request packet.
>
> What is worth guarding, it tor control socket, and it isn't directly
> exposed. There is "control-port-filter-python" (or something else in new
> Whonix version?) to filter it. IMO it would be much better if control
> port wouldn't be exposed at all, but unfortunately some applications do
> require it.
>

[entr0py]

William Budington:

> I wasn't aware of the IsolateClientAddr option within tor. With the
> assurance that each source ip will be stream isolated, no `tun2socks`
> proxy or equivalent is necessary, given that whonix-ws is
> transparently torified.

Other Tor options of interest to you: `IsolateDestPort`, `IsolateDestAddr`, `IsolateSOCKSAuth`. SOCKSAuth is a hacky way to provide intra-application stream isolation (examples: Tor Browser, coyIM).

Essential to read if you haven't: https://www.whonix.org/wiki/Stream_Isolation

Also, besides using Arm, I would recommend playing around with Onioncircuits by Tails[1] in your Gateway to monitor circuits in real-time. The advantage it has over Arm is that it associates destination IPs with each circuit making them easy for you to identify. (Package is available in jessie-backports).

> For applications that do not require direct
> tor port access, separating them into their own VM and modifying
> iptables rules on sys-whonix so that these VMs have no access to the
> tor ports should work for my intended purpose.

Applications that aren't torrified / socksified can be denied network access by disabling the Transparent Proxy port.[2]

> Since the browser is such a large attack surface, for whonix-ws VMs
> which only use Tor Browser, I wonder if access to the control port
> could be fully denied?

Yes, documented here for Whonix 13: https://www.whonix.org/wiki/Advanced_Security_Guide#Disable_Control_Port_Filter_Proxy

The proxy is largely in place to prevent falsely alarming users who do not understand the error messages spawned by not having access to the control port, and as you said, to enable `New Identity`. The `New Identity` function is relatively less useful in Qubes since VM-level stream isolation is so easy.

If you haven't looked yet, the list of whitelisted commands is in the drop-in config directory: /etc/cpfpy.d/ I haven't checked which commands are whitelisted in the new Tails filter.


[1] https://tails.boum.org/doc/anonymous_internet/tor_status/index.en.html#index2h1
[2] https://www.whonix.org/wiki/Stream_Isolation#Better_Protection

[Patrick Schleizer]

William Budington:

> Since the browser is such a large attack surface, for whonix-ws VMs
> which only use Tor Browser, I wonder if access to the control port
> could be fully denied? It seems so. Since the Tor Launcher isn't
> actually bootstrapping tor, the control port is only used for the
> "New Identity" functionality, so you'll lose that. But if you kill
> the `socat` process forwarding 9151, the browser seems to work fine.

[Btw to kill all socat for testing one can use: "sudo service
anon-ws-disable-stacked-tor stop"]

> It seems like the "New Identity" functionality could be implemented
> on the whonix-gw side:
> https://blog.torproject.org/category/tags/new-identity
>
> Looks like the Tor Browser use of the control port isn't going away,
> though. And in fact may be increasing in the future:
> https://trac.torproject.org/projects/tor/ticket/9675

Yes. That's why we have the filter.

Btw the full rationale can be found here:
https://www.whonix.org/wiki/Dev/Control_Port_Filter_Proxy

Best regards,
Patrick