The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:04:27Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8788We can crash on a bad resolv.conf file2020-06-27T14:04:27ZNick MathewsonWe can crash on a bad resolv.conf fileWhen we use NEXT_TOKEN in resolv_conf_parse_line, we unconditionally call evdns_nameserver_ip_add() on the result, when it might be NULL.
resolv.conf isn't adversary-controlled, so this isn't a huge deal, but we should fix it. Libevent...When we use NEXT_TOKEN in resolv_conf_parse_line, we unconditionally call evdns_nameserver_ip_add() on the result, when it might be NULL.
resolv.conf isn't adversary-controlled, so this isn't a huge deal, but we should fix it. Libevent should get this fix too.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8787Check return values for more unix functions2020-07-24T14:58:06ZNick MathewsonCheck return values for more unix functionsReportedly, we lack checks for the return values of at least munmap, lseek, unlink. We should fix that for code-quality.Reportedly, we lack checks for the return values of at least munmap, lseek, unlink. We should fix that for code-quality.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8786Add extra-info line that tracks the number of consensus downloads over each p...2022-05-23T20:34:06ZGeorge KadianakisAdd extra-info line that tracks the number of consensus downloads over each pluggable transportIn legacy/trac#5040, Karsten suggested to add yet another line for measuring obfsbridge stats.
He wants a `dirreq-v3-transport` line with the exact same format as `bridge-ip-transports`, that counts consensus fetches instead of direct c...In legacy/trac#5040, Karsten suggested to add yet another line for measuring obfsbridge stats.
He wants a `dirreq-v3-transport` line with the exact same format as `bridge-ip-transports`, that counts consensus fetches instead of direct connections. This will improve the granularity of bridge statistics, and it will help us count users accurately in scenarios like flashproxy (where each client is actually a flashproxy bridge).
This means that we should be considering the `GEOIP_CLIENT_NETWORKSTATUS_V2` and `GEOIP_CLIENT_NETWORKSTATUS` events in this case, instead of `GEOIP_CLIENT_CONNECT`.https://gitlab.torproject.org/tpo/core/tor/-/issues/8782Don't give up so easily on your guards if the consensus calls them Running2020-06-27T14:04:28ZRoger DingledineDon't give up so easily on your guards if the consensus calls them RunningIf your guard ever fails to do everything you demand, you'll mark it as not running for several hours (i.e. until you get a new consensus that tells you to forgive it). So an attack to railroad you onto the adversary's guard (even if tem...If your guard ever fails to do everything you demand, you'll mark it as not running for several hours (i.e. until you get a new consensus that tells you to forgive it). So an attack to railroad you onto the adversary's guard (even if temporarily, which isn't so bad for a normal client but is super scary for a hidden service) gets cheaper.
It would be wise to forgive guards in the "we decided they're down but our consensus still says they're up" state much more quickly and often. That changes the attack from a serial "get us to mark each guard down one at a time" to either requiring you to do it in a much shorter time frame, or the more expensive parallel "keep a growing set of guards all down until the victim chooses ours".
(A discussion with rpw at 29c3 reminded me of this issue, and now ongoing discussions with Rob re-remind me of it.)Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8771GEO IP file directory is wrong2020-06-27T14:04:28ZTracGEO IP file directory is wrongTor is checking this directory and failing:
Apr 25 01:13:09.076 [Warning] Failed to open GEOIP file C:\Users\*snip*\AppData\Roaming\tor\geoip. We've been configured to see which countries can access us as a bridge, and we need GEOIP inf...Tor is checking this directory and failing:
Apr 25 01:13:09.076 [Warning] Failed to open GEOIP file C:\Users\*snip*\AppData\Roaming\tor\geoip. We've been configured to see which countries can access us as a bridge, and we need GEOIP information to tell which countries clients are in.
The actual files are stored in:
C:\Users\*snip*\AppData\Local\Tor
There seems to be some serious mismatch between the use of the Local directory and the roaming directory. For example all other Tor configuration data is stored in the roaming directory, only the GEOIP stuff is stored in the Local directory.
Vidalia seems to store all content in the Local directory, not the roaming directory.
**Trac**:
**Username**: funkstarTor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8766Tor never recovers when started with skewed clock2020-06-27T14:04:28ZproperTor never recovers when started with skewed clockHow to reproduce...
Start Tor with a skewed clock. For example, +/- one week.
Tor will detect, that the clock is skewed.
```
Received directory with skewed time (server '...'):
It seems that our clock is ahead by 6 days, 23 hours,
59 ...How to reproduce...
Start Tor with a skewed clock. For example, +/- one week.
Tor will detect, that the clock is skewed.
```
Received directory with skewed time (server '...'):
It seems that our clock is ahead by 6 days, 23 hours,
59 minutes, or that theirs is behind. Tor requires an
accurate clock to work: please check your time,
timezone, and date settings.
I learned some more directory information, but not
enough to build a circuit: We have no recent usable
consensus.
```
Then reset clock back to correct time. Tor will also detect that.
```
Your system clock just jumped 604800 seconds backward;
assuming established circuits no longer work.
```
Result:
Tor still won't work (no connections possible).
Expected result:
Tor recovers and can now connect.
Version:
getinfo version: 250-version=0.2.3.25 (git-3fed5eb096d2d187)
(On Debian Wheezy.)Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8749Return information about the leaking application2021-06-18T18:21:28ZbastikReturn information about the leaking applicationLog from where the leaking request came.
When Tor says (in the Vidalia log):
> Potentially Dangerous Connection! - One of your applications established a connection through Tor to "!IP:PORT" using a protocol that may leak information a...Log from where the leaking request came.
When Tor says (in the Vidalia log):
> Potentially Dangerous Connection! - One of your applications established a connection through Tor to "!IP:PORT" using a protocol that may leak information about your destination. Please ensure you configure your applications to use only SOCKS4a or SOCKS5 with remote hostname resolution.
could Tor tell what port the connection was made from? Maybe the log could include SOCKS details (like username). I don't think it isn't able to identify the application.
Sure it's bad to use random stuff with Tor, but this information makes it easier to sort out applications that leak.https://gitlab.torproject.org/tpo/core/tor/-/issues/8748Update path-specs to educate about family2020-06-27T14:04:29ZbastikUpdate path-specs to educate about familyI'm not sure what Component I should select.
As suggested here:
https://lists.torproject.org/pipermail/tor-talk/2013-April/027872.html
based on my email on tor-talk:
https://lists.torproject.org/pipermail/tor-talk/2013-April/027869.htm...I'm not sure what Component I should select.
As suggested here:
https://lists.torproject.org/pipermail/tor-talk/2013-April/027872.html
based on my email on tor-talk:
https://lists.torproject.org/pipermail/tor-talk/2013-April/027869.html
I suggest to update the path-specs with an explanation on how excluding family works.
The dir-specs hold a nice (from my POV) explanation and gives an example.
> If two ORs list one another in their "family" entries, then OPs should treat them as a single OR for the purpose of path selection.
> For example, if node A's descriptor contains "family B", and node B's descriptor contains "family A", then node A and node B should never be used on the same circuit.
The reason I suggest this is because I believe it is to be expected in the path-specs, rather than in the dir-spec. I'm ***not*** suggesting to remove it from any other document this explanation is in.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8746Tor tries to kill nonexistent proxy PID on second SIGINT2020-06-27T14:04:29ZDavid Fifielddcf@torproject.orgTor tries to kill nonexistent proxy PID on second SIGINTThis is what 180-pluggable-transport.txt says about proxies and SIGINT:
Proxies should respond to a single INT signal by closing their listener ports and not accepting any new connections, but keeping all connections open, then termin...This is what 180-pluggable-transport.txt says about proxies and SIGINT:
Proxies should respond to a single INT signal by closing their listener ports and not accepting any new connections, but keeping all connections open, then terminating when connections are all closed. Proxies should respond to a second INT signal by shutting down cleanly.
I implemented the websocket-server transport to work as specified:
https://gitweb.torproject.org/flashproxy.git/blob/c23caf1f71f8281319cadf55002723dbcd333905:/websocket-transport/websocket-server.go#l238
I noticed unexpected behavior when the proxy receives a SIGINT, and doesn't have any open connection, and so exits immediately without waiting for a second SIGINT. The parent tor process tries to kill a nonexistent PID:
```
^CApr 19 17:58:59.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now.
^CApr 19 17:59:05.000 [notice] SIGINT received a second time; exiting now.
Apr 19 17:59:05.000 [notice] Failed to terminate process with PID '18277' ('No such process').
```
The PID might have been reclaimed in the meantime, and tor could be killing an unrelated process.
(Originally from https://lists.torproject.org/pipermail/tor-dev/2013-April/004679.html.)Tor: 0.2.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8742Byte history leaks information about local usage/hidden services2022-05-23T20:36:15ZTracByte history leaks information about local usage/hidden servicesNot sure if this is related to legacy/trac#516.
When acting as a relay, Tor seems to collect and report on *all* incoming and outgoing bandwidth. This data is then published publicly on Atlas, torstatus, or available for download.
As ...Not sure if this is related to legacy/trac#516.
When acting as a relay, Tor seems to collect and report on *all* incoming and outgoing bandwidth. This data is then published publicly on Atlas, torstatus, or available for download.
As an example, if you look at the monthly graph, it's pretty clear this relay become "something more than a relay" around the 7th of April:
https://atlas.torproject.org/#details/85617CE64344948B0BAC23CD4E22245F7F66C1C8
An attacker could use this data to determine if a relay hosts a hidden service (generally more bytes written than read), or if a user was actively browsing/downloading (more bytes read, generally) during a certain period of time. An active attacker could then create a large amount of traffic to a hidden service, perhaps creating a known pattern of high traffic followed by a period of little traffic, then review the byte history again and look for any relays that displayed a difference of read/write similar to the generated traffic. Having narrowed down the candidates, a DDOS of the relay would provide confirmation. Exposing clients would of course be far more difficult, as most probably do not run as a relay.
Possible solutions:
*By default, don't count any traffic to/from a hidden service. Could be enabled optionally in torrc... if someone really wanted it.
*By default, don't count any traffic beginning at tor's socks port. I can't think of any reason someone would want to enable this... but if there is a good argument for it, perhaps provide an option in torrc for this too.
*Most drastically... let a user opt out of reporting byte history completely. I'm guessing this is a "no go", since the stats are needed to help better network performance.
**Trac**:
**Username**: alphawolfhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8719memory leak when we get a consensus but don't have enough certs to check it2020-06-27T14:04:29ZRoger Dingledinememory leak when we get a consensus but don't have enough certs to check it```
==8808== 685,222 bytes in 1 blocks are definitely lost in loss record 28 of 28
==8808== at 0x4C28BED: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64
-linux.so)
==8808== by 0x5FDEB41: strdup (strdup.c:43)
==8808== by 0...```
==8808== 685,222 bytes in 1 blocks are definitely lost in loss record 28 of 28
==8808== at 0x4C28BED: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64
-linux.so)
==8808== by 0x5FDEB41: strdup (strdup.c:43)
==8808== by 0x22114D: tor_strdup_ (util.c:240)
==8808== by 0x1275A0: networkstatus_set_current_consensus (networkstatus.c:1718)
==8808== by 0x1E555B: connection_dir_client_reached_eof (directory.c:1875)
==8808== by 0x1E6F28: connection_dir_reached_eof (directory.c:2311)
==8808== by 0x1C1496: connection_handle_read (connection.c:4119)
==8808== by 0x11DEA0: conn_read_callback (main.c:718)
==8808== by 0x52D8CCB: event_base_loop (in /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5.1.7)
==8808== by 0x11E834: do_main_loop (main.c:1980)
==8808== by 0x12001D: tor_main (main.c:2696)
==8808== by 0x5F7CEAC: (below main) (libc-start.c:228)
```Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8718memory leak whenever a config change happens2020-06-27T14:04:29ZRoger Dingledinememory leak whenever a config change happens```
==10870== 10 bytes in 1 blocks are definitely lost in loss record 1 of 27
==10870== at 0x4C28BED: malloc (vg_replace_malloc.c:263)
==10870== by 0x5FDEB41: strdup (strdup.c:43)
==10870== by 0x22111D: tor_strdup_ (in /usr/sbin...```
==10870== 10 bytes in 1 blocks are definitely lost in loss record 1 of 27
==10870== at 0x4C28BED: malloc (vg_replace_malloc.c:263)
==10870== by 0x5FDEB41: strdup (strdup.c:43)
==10870== by 0x22111D: tor_strdup_ (in /usr/sbin/tor)
==10870== by 0x1B8C04: config_get_assigned_option (in /usr/sbin/tor)
==10870== by 0x1B580A: set_options (in /usr/sbin/tor)
==10870== by 0x1B70FC: options_trial_assign (in /usr/sbin/tor)
==10870== by 0x1D3FCD: control_setconf_helper (in /usr/sbin/tor)
==10870== by 0x1D7584: connection_control_process_inbuf (in /usr/sbin/tor)
==10870== by 0x1C11CC: connection_handle_read (in /usr/sbin/tor)
==10870== by 0x11DEA0: conn_read_callback (in /usr/sbin/tor)
==10870== by 0x52D8CCB: event_base_loop (in /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5.1.7)
==10870== by 0x11E834: do_main_loop (in /usr/sbin/tor)
==10870==
==10870== 42 bytes in 1 blocks are definitely lost in loss record 13 of 27
==10870== at 0x4C28BED: malloc (vg_replace_malloc.c:263)
==10870== by 0x220DE7: tor_malloc_ (in /usr/sbin/tor)
==10870== by 0x216DF2: smartlist_join_strings2 (in /usr/sbin/tor)
==10870== by 0x1B8C9A: config_get_assigned_option (in /usr/sbin/tor)
==10870== by 0x1B580A: set_options (in /usr/sbin/tor)
==10870== by 0x1B70FC: options_trial_assign (in /usr/sbin/tor)
==10870== by 0x1D3FCD: control_setconf_helper (in /usr/sbin/tor)
==10870== by 0x1D7584: connection_control_process_inbuf (in /usr/sbin/tor)
==10870== by 0x1C11CC: connection_handle_read (in /usr/sbin/tor)
==10870== by 0x11DEA0: conn_read_callback (in /usr/sbin/tor)
==10870== by 0x52D8CCB: event_base_loop (in /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5.1.7)
==10870== by 0x11E834: do_main_loop (in /usr/sbin/tor)
```Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8716HashedControlPassword Doesn't Seem To Do Anything2020-06-27T14:04:30ZcypherpunksHashedControlPassword Doesn't Seem To Do AnythingAfter setting HashedControlPassword, I'm able to connect to the control port without being prompted for my password. Further, I can actually manually change the hash (for example, I can change the last few characters all to 'F'), and arm...After setting HashedControlPassword, I'm able to connect to the control port without being prompted for my password. Further, I can actually manually change the hash (for example, I can change the last few characters all to 'F'), and arm is still able to connect without prompting me. I've attached my torrc with the nickname and contact info removed.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8712Authorities should not vote against Fast just because they vote against Running2020-06-27T14:04:30ZRoger DingledineAuthorities should not vote against Fast just because they vote against RunningNon-active relays get stripped of their Fast flag, even if the bwauth measurements put them above the Fast threshold.
Seems to me that if enough other authorities find the relay to be Running, we shouldn't be voting against giving him t...Non-active relays get stripped of their Fast flag, even if the bwauth measurements put them above the Fast threshold.
Seems to me that if enough other authorities find the relay to be Running, we shouldn't be voting against giving him the Fast flag.
Probably same with other flags like Guard, Stable, and Exit.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8711authorities should say on their flag-threshold lines in their vote whether th...2020-06-27T14:04:30ZRoger Dingledineauthorities should say on their flag-threshold lines in their vote whether they have enough Measured lines that they're counting non-Measured relays as 0 bandwidthauthorities should say on their flag-threshold lines in their vote whether they have enough Measured lines that they're counting non-Measured relays as 0 bandwidth
that will help karsten to track and explain changes over timeauthorities should say on their flag-threshold lines in their vote whether they have enough Measured lines that they're counting non-Measured relays as 0 bandwidth
that will help karsten to track and explain changes over timeTor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8710Sybil selection should prefer measured over advertised bw2020-06-27T14:04:30ZNick MathewsonSybil selection should prefer measured over advertised bwWhen choosing between two nodes on the same IP, we based the choice on bandwidth. But right now, we use dirserv_get_bandwidth_for_router(), which looks at measured bw and falls back to advertised when measured isn't present. Probably it...When choosing between two nodes on the same IP, we based the choice on bandwidth. But right now, we use dirserv_get_bandwidth_for_router(), which looks at measured bw and falls back to advertised when measured isn't present. Probably it makes more sense, if there are two nodes, one of which has measured bw and one of which doesn't, to prefer the one with measured bw.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8701Stem doesn't recognize error 555 on attach_stream2020-06-27T14:04:30ZcypherpunksStem doesn't recognize error 555 on attach_streamWhen trying to attach a stream that is not controlled by the controller using Controller.attach_stream, Tor will reply with error 555. Stem does not recognize this and will throw a generic exception:
```
stem.ProtocolError: ATTACHSTREAM...When trying to attach a stream that is not controlled by the controller using Controller.attach_stream, Tor will reply with error 555. Stem does not recognize this and will throw a generic exception:
```
stem.ProtocolError: ATTACHSTREAM returned unexpected response code: 555
```
I think an InvalidArguments exception would be best suited for this error code.
```
@@ -1981,6 +1981,8 @@ class Controller(BaseController):
raise stem.InvalidRequest(response.code, response.message)
elif response.code == '551':
raise stem.OperationFailed(response.code, response.message)
+ elif response.code == '555':
+ raise stem.InvalidArguments(response.code, response.message)
else:
raise stem.ProtocolError("ATTACHSTREAM returned unexpected response code: %s" % response.code)
```Tor: 0.2.4.x-finalDamian JohnsonDamian Johnsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8700Tor attaches streams to newly created circuits even with __LeaveStreamsUnatta...2020-06-27T14:04:30ZcypherpunksTor attaches streams to newly created circuits even with __LeaveStreamsUnattached=1When Tor created a new circuit it checks for streams that are not attached yet and attaches them to the new circuit. This is normally fine, but it should not be done when !__LeaveStreamsUnattached is set to 1.When Tor created a new circuit it checks for streams that are not attached yet and attaches them to the new circuit. This is normally fine, but it should not be done when !__LeaveStreamsUnattached is set to 1.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8685Document how authorities choose relay status flags2020-06-27T14:04:30ZRoger DingledineDocument how authorities choose relay status flagslegacy/trac#8273 and legacy/trac#8435 are confusing in part because we don't know what they're trying to do. We should decide what they ought to do (starting I guess with deciding with what we think they did), and document that in dir-sp...legacy/trac#8273 and legacy/trac#8435 are confusing in part because we don't know what they're trying to do. We should decide what they ought to do (starting I guess with deciding with what we think they did), and document that in dir-spec (or somewhere else that's appropriate). That way when we find something weird looking, there's a way to decide whether it's a bug.
In an ideal world, in retrospect, this topic probably could have used a short proposal.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8683moria1 isn't voting for Fast flag when it should2020-06-27T14:04:31ZRoger Dingledinemoria1 isn't voting for Fast flag when it shouldmoria1 running master (and thus legacy/trac#8273 and legacy/trac#8435) is voting weirdly about its flags -- particularly Fast and Exit.
For example, this one really ought to get Fast:
```
r Ferrari458 ABwTs6Vacbl3ymXshVOdecZTo/w r5fmkGF...moria1 running master (and thus legacy/trac#8273 and legacy/trac#8435) is voting weirdly about its flags -- particularly Fast and Exit.
For example, this one really ought to get Fast:
```
r Ferrari458 ABwTs6Vacbl3ymXshVOdecZTo/w r5fmkGFLqpZj8tHabjbPP5IidFo 2013-04-11 03:37:00 68.38.171.200 9001 9030
s HSDir Running V2Dir Valid
v Tor 0.2.3.25
w Bandwidth=605 Measured=1120
p reject 1-65535
m 8,9,10,11,12,13,14,15,16,17 sha256=oRdjVNraRMF9pWQJzl8UxZdfNBoHSWF0GlYWailMsBU
```
And this one really ought to get Exit:
```
r sumkledi ABPSI4nNUNC3hKPkBhyzHozozrU S6rBWKQIhhXr/+EVxRX/DT9AB8I 2013-04-11 04:01:46 178.218.213.229 80 0
s Running Valid
v Tor 0.2.2.35
w Bandwidth=51 Measured=20
p accept 80,443
m 8,9,10,11,12,13,14,15,16,17 sha256=9K0eJJ5HKhiAianDAkw+0Zs8WFIUDE9D6p/VY3w0WOE
```Tor: 0.2.4.x-final