Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#18156 closed defect (wontfix)

Add a torrc flag to disable ADD_ONION creation.

Reported by: cypherpunks Owned by:
Priority: Medium Milestone:
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-hs, control
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor: SponsorR-can


Please add a flag, that can be set in /etc/tor/torrc to forbid the tor client from creating onion services, using the control port command ADD_ONION.

Letting the default be permissive is reasonable.

This can be useful for the tor-browser and tails that don't need ADD_ONION under normal circumstances.

Child Tickets

Change History (8)

comment:1 Changed 4 years ago by atagar

Component: - Select a componentTor

Hi cypherpunks. This is essentially a request to enable/disable select bits of the control protocol. This strikes me as a slippery slope. What's next? Torrc options to disable SETCONF? EXTENDCIRCUIT?

I can see this quickly proliferating torrc options and we have too many already. Something I suspect would be better would be an option to make the control port read-only. That is to say, only accept GETINFO, GETCONF, SETEVENTS, and other commands that don't modify tor. Iirc we've discussed this before and it would be a neat thing for nyx to have (since it generally aims to be a read-only controller).

comment:2 Changed 4 years ago by cypherpunks

Hi atagar, I could be very much wrong about this, but I'm concerned about ADD_ONION because with the help of legitimate but buggy third party software, it can bypass my firwall rules and hook up to my ssh server, or mail server or local network and potentially make me part of a bot net or worse, instead of just hooking up to the buggy applications listening port. And there isn't really an easy way of seeing it. #18157

I don't know if SETCONF or SETEVENTS can do that.

I'm all for the read-only control port. I hope it is considered.

comment:3 Changed 4 years ago by atagar

There's certainly nasty things that can be done with SETCONF and EXTENDCIRCUIT. Deanonymization by maliciously constructed custom circuits come to mind. But you might be right about ADD_ONION being even more dangerous (can't say for sure).

comment:4 Changed 4 years ago by nickm

Milestone: Tor: 0.2.???

comment:5 Changed 3 years ago by dgoulet

Keywords: tor-hs control added
Sponsor: SponsorR-can

This is indeed a worrying issue imo. There are multiple options here I see:

  1. Add a torrc option to disable ADD_ONION for only client
  2. atagar's suggestion is to have a read-only option for control port.
  3. Add a torrc option which tells tor that it's a client-only so no HS would be possible. Actually, any "opening listening socket" apart from SocksPort would be denied.

More on that. I actually think that a default tor client (only acting as a client that is no ORPort) should never allow ADD_ONION unless explicitly requested in the torrc. It sounds like a lot to ask to users to _close_ down the command instead of opening it if needed (most of the time used by specific apps).

comment:6 Changed 3 years ago by dgoulet

Resolution: wontfix
Status: newclosed

After discussion on #tor-dev, with an open control port, if an attacker is able to give it command, you are doomed by design.

The correct but very difficult way to fix this would be to have a control command filter that is a subset of commands that could be consider "safe" which is a HARD problem to solve because it depends heavily on the thread model of the user/app. See ticket #8369 about this.

Closing this one as wontfix.

comment:7 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:8 Changed 3 years ago by nickm

Milestone: Tor: 0.3.???

Milestone deleted

Note: See TracTickets for help on using tickets.