The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-07-14T18:47:00Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33103LeakSanitizer is kicking in with tor being on 39c5e1b84994c2f226a8530b930f215...2020-07-14T18:47:00ZGeorg KoppenLeakSanitizer is kicking in with tor being on 39c5e1b84994c2f226a8530b930f215cc5ffb877 when closing Tor BrowserI just updated my hardened Tor Browser setup and I got LeakSanitizer issues when closing Tor Browser. That's with `tor` being on `39c5e1b84994c2f226a8530b930f215cc5ffb877`:
```
==10555==ERROR: LeakSanitizer: detected memory leaks
Direct...I just updated my hardened Tor Browser setup and I got LeakSanitizer issues when closing Tor Browser. That's with `tor` being on `39c5e1b84994c2f226a8530b930f215cc5ffb877`:
```
==10555==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 6762 byte(s) in 4 object(s) allocated from:
#0 0x7f0d81c53628 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x107628)
#1 0x55863eead50a in tor_malloc_ ../src/lib/malloc/malloc.c:45
#2 0x55863ee86121 in smartlist_join_strings2 ../src/lib/container/smartlist.c:309
#3 0x55863ec2bb08 in getinfo_helper_events ../src/feature/control/control_getinfo.c:1169
#4 0x55863ec31d53 in handle_getinfo_helper ../src/feature/control/control_getinfo.c:1696
#5 0x55863ec31d53 in handle_control_getinfo ../src/feature/control/control_getinfo.c:1721
#6 0x55863ec1e092 in handle_single_control_command ../src/feature/control/control_cmd.c:2374
#7 0x55863ec1e092 in handle_control_command ../src/feature/control/control_cmd.c:2405
#8 0x55863ec0fa91 in connection_control_process_inbuf ../src/feature/control/control.c:508
#9 0x55863eb19c21 in connection_handle_read_impl ../src/core/mainloop/connection.c:3737
#10 0x55863eb19c21 in connection_handle_read ../src/core/mainloop/connection.c:3777
#11 0x55863eb25ce0 in conn_read_callback ../src/core/mainloop/mainloop.c:892
#12 0x7f0d819b4b0e (/usr/lib/x86_64-linux-gnu/libevent-2.1.so.7+0x23b0e)
Direct leak of 2244 byte(s) in 12 object(s) allocated from:
#0 0x7f0d81c53628 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x107628)
#1 0x55863eead50a in tor_malloc_ ../src/lib/malloc/malloc.c:45
#2 0x55863ee86121 in smartlist_join_strings2 ../src/lib/container/smartlist.c:309
#3 0x55863ed0e522 in routerstatus_format_entry ../src/feature/nodelist/fmt_routerstatus.c:197
#4 0x55863ece1718 in networkstatus_getinfo_helper_single ../src/feature/nodelist/networkstatus.c:2353
#5 0x55863ece1718 in getinfo_helper_networkstatus ../src/feature/nodelist/networkstatus.c:2694
#6 0x55863ec31d53 in handle_getinfo_helper ../src/feature/control/control_getinfo.c:1696
#7 0x55863ec31d53 in handle_control_getinfo ../src/feature/control/control_getinfo.c:1721
#8 0x55863ec1e092 in handle_single_control_command ../src/feature/control/control_cmd.c:2374
#9 0x55863ec1e092 in handle_control_command ../src/feature/control/control_cmd.c:2405
#10 0x55863ec0fa91 in connection_control_process_inbuf ../src/feature/control/control.c:508
#11 0x55863eb19c21 in connection_handle_read_impl ../src/core/mainloop/connection.c:3737
#12 0x55863eb19c21 in connection_handle_read ../src/core/mainloop/connection.c:3777
#13 0x55863eb25ce0 in conn_read_callback ../src/core/mainloop/mainloop.c:892
#14 0x7f0d819b4b0e (/usr/lib/x86_64-linux-gnu/libevent-2.1.so.7+0x23b0e)
Direct leak of 147 byte(s) in 2 object(s) allocated from:
#0 0x7f0d81bde0b5 in strdup (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x920b5)
#1 0x55863eead7a0 in tor_strdup_ ../src/lib/malloc/malloc.c:165
#2 0x55863ec2bdb7 in getinfo_helper_events ../src/feature/control/control_getinfo.c:1289
#3 0x55863ec31d53 in handle_getinfo_helper ../src/feature/control/control_getinfo.c:1696
#4 0x55863ec31d53 in handle_control_getinfo ../src/feature/control/control_getinfo.c:1721
#5 0x55863ec1e092 in handle_single_control_command ../src/feature/control/control_cmd.c:2374
#6 0x55863ec1e092 in handle_control_command ../src/feature/control/control_cmd.c:2405
#7 0x55863ec0fa91 in connection_control_process_inbuf ../src/feature/control/control.c:508
#8 0x55863eb19c21 in connection_handle_read_impl ../src/core/mainloop/connection.c:3737
#9 0x55863eb19c21 in connection_handle_read ../src/core/mainloop/connection.c:3777
#10 0x55863eb25ce0 in conn_read_callback ../src/core/mainloop/mainloop.c:892
#11 0x7f0d819b4b0e (/usr/lib/x86_64-linux-gnu/libevent-2.1.so.7+0x23b0e)
Direct leak of 36 byte(s) in 12 object(s) allocated from:
#0 0x7f0d81bde0b5 in strdup (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x920b5)
#1 0x55863eead7a0 in tor_strdup_ ../src/lib/malloc/malloc.c:165
#2 0x55863ec34aba in getinfo_helper_geoip ../src/feature/control/getinfo_geoip.c:51
#3 0x55863ec31d53 in handle_getinfo_helper ../src/feature/control/control_getinfo.c:1696
#4 0x55863ec31d53 in handle_control_getinfo ../src/feature/control/control_getinfo.c:1721
#5 0x55863ec1e092 in handle_single_control_command ../src/feature/control/control_cmd.c:2374
#6 0x55863ec1e092 in handle_control_command ../src/feature/control/control_cmd.c:2405
#7 0x55863ec0fa91 in connection_control_process_inbuf ../src/feature/control/control.c:508
#8 0x55863eb19c21 in connection_handle_read_impl ../src/core/mainloop/connection.c:3737
#9 0x55863eb19c21 in connection_handle_read ../src/core/mainloop/connection.c:3777
#10 0x55863eb25ce0 in conn_read_callback ../src/core/mainloop/mainloop.c:892
#11 0x7f0d819b4b0e (/usr/lib/x86_64-linux-gnu/libevent-2.1.so.7+0x23b0e)
Direct leak of 17 byte(s) in 1 object(s) allocated from:
#0 0x7f0d81c53628 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x107628)
#1 0x55863eead50a in tor_malloc_ ../src/lib/malloc/malloc.c:45
#2 0x55863ee86121 in smartlist_join_strings2 ../src/lib/container/smartlist.c:309
#3 0x55863ec2ceca in getinfo_helper_listeners ../src/feature/control/control_getinfo.c:298
#4 0x55863ec31d53 in handle_getinfo_helper ../src/feature/control/control_getinfo.c:1696
#5 0x55863ec31d53 in handle_control_getinfo ../src/feature/control/control_getinfo.c:1721
#6 0x55863ec1e092 in handle_single_control_command ../src/feature/control/control_cmd.c:2374
#7 0x55863ec1e092 in handle_control_command ../src/feature/control/control_cmd.c:2405
#8 0x55863ec0fa91 in connection_control_process_inbuf ../src/feature/control/control.c:508
#9 0x55863eb19c21 in connection_handle_read_impl ../src/core/mainloop/connection.c:3737
#10 0x55863eb19c21 in connection_handle_read ../src/core/mainloop/connection.c:3777
#11 0x55863eb25ce0 in conn_read_callback ../src/core/mainloop/mainloop.c:892
#12 0x7f0d819b4b0e (/usr/lib/x86_64-linux-gnu/libevent-2.1.so.7+0x23b0e)
SUMMARY: AddressSanitizer: 9206 byte(s) leaked in 31 allocation(s).
```Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33104Minor issues when handling ACTIVE control signal2020-07-14T22:24:16ZGeorge KadianakisMinor issues when handling ACTIVE control signalThe ACTIVE control signal is not handled in `control_event_signal()` which results in:
`control_event_signal(): Bug: Unrecognized signal 132 in control_event_signal` messages when it appears.
There is also a mistype in the following co...The ACTIVE control signal is not handled in `control_event_signal()` which results in:
`control_event_signal(): Bug: Unrecognized signal 132 in control_event_signal` messages when it appears.
There is also a mistype in the following comment `/* "SIGACTIVE" counts as ersatz user activity. *`Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33118Investigate clusterfuzz timeouts2020-06-27T13:48:23ZNick MathewsonInvestigate clusterfuzz timeoutsClusterfuzz has found some test cases which in its opinion take too much time or memory. I don't see how this is possible, since they each complete within a second on my desktop, but we should aim for better performance than that, and w...Clusterfuzz has found some test cases which in its opinion take too much time or memory. I don't see how this is possible, since they each complete within a second on my desktop, but we should aim for better performance than that, and we should try to eliminate even our false positives.
And who knows, maybe there's a real bug here?Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34137Make sure inform_testing_reachability() reports the correct ports2021-09-16T14:21:52ZteorMake sure inform_testing_reachability() reports the correct portsIn legacy/trac#33222, we added IPv6 ORPort support to inform_testing_reachability(). But that function checks the ORPorts and DirPort itself, rather than logging the reachability checks that were actually launched.
We'd like to pass fla...In legacy/trac#33222, we added IPv6 ORPort support to inform_testing_reachability(). But that function checks the ORPorts and DirPort itself, rather than logging the reachability checks that were actually launched.
We'd like to pass flags so that it logs the actual reachability tests that are being run. (Rather than re-checking the relay's own routerinfo, which may have changed since the most recent reachability checks were launched.)
But inform_testing_reachability() is called when:
* the first circuit finishes building, or
* tor is reconfigured, and some circuits have already finished building.
So we need to do a bit of a refactor.
The refactor should preserve this behaviour:
* don't log until after the first circuit has finished building (rather than logging as soon as we start building reachability circuits)
And introduce this new behaviour:
* log the ports that were tested recently, rather than the ports that are currently available.
As an alternative, we could move some of the logging into the functions that actually launch the checks. And elevate some of those logs to notice level. (Note that these checks can be launched from at least 4 different locations in tor's code.)Tor: unspecifiedNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16016extrainfo_insert(): Bug: No entry found in extrainfo map.2020-07-02T11:22:42ZRoger Dingledineextrainfo_insert(): Bug: No entry found in extrainfo map.I get these on moria1 pretty often. It's been ongoing for a long time I think -- since whenever we attempted to fix that last bug with ri / ei synchronization.
Here's a potentially useful info-level log:
```
May 13 18:50:37.600 [info] c...I get these on moria1 pretty often. It's been ongoing for a long time I think -- since whenever we attempted to fix that last bug with ri / ei synchronization.
Here's a potentially useful info-level log:
```
May 13 18:50:37.600 [info] connection_dir_client_reached_eof(): Received extra server info (size 5307) from server '131.188.40.189:80'
May 13 18:50:37.600 [info] router_load_extrainfo_from_string(): 3 elements to add
May 13 18:50:37.600 [warn] extrainfo_insert(): Bug: No entry found in extrainfo map. [1 similar message(s) suppressed in last 1800 seconds] (on Tor 0.2.7.1-alpha-dev 95a9920461dd3322)
May 13 18:50:37.623 [info] connection_dir_client_reached_eof(): Received 0/9 extra-info documents requested from 131.188.40.189:80
```
I don't know if this last line is related or not.
Actually, I get one of the Bug: messages every hour on moria1, a little bit after the 50 minute mark. Sounds like I'm hearing votes from other authorities, and they make me think of an extrainfo I don't have, so I try to get it, and then bug.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34069Allow extend_info to contain both IPv4 and IPv6 ORPorts2020-10-22T15:12:33ZteorAllow extend_info to contain both IPv4 and IPv6 ORPortsTo send dual-stack EXTEND2 cells in legacy/trac#33222, we need to have IPv4 and IPv6 addresses in extend_info_t.To send dual-stack EXTEND2 cells in legacy/trac#33222, we need to have IPv4 and IPv6 addresses in extend_info_t.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32661Document that we avoid changing src/ext2021-07-22T16:19:07ZteorDocument that we avoid changing src/extWe only change src/ext when necessary for integration with tor, or portability across platforms.
There was some confusion about this in legacy/trac#32626, so I'd like to update one or more of the following documents:
* src/mainpage.md
*...We only change src/ext when necessary for integration with tor, or portability across platforms.
There was some confusion about this in legacy/trac#32626, so I'd like to update one or more of the following documents:
* src/mainpage.md
* src/ext/README
* doc/HACKING/CodeStructure.md
We might also want to change our merge policy, but that's a longer process.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33120Resolve TROVE-2020-0022020-06-27T13:48:23ZNick MathewsonResolve TROVE-2020-002This is the description I posted in the changelog:
```
TROVE-2020-002 is a vulnerability affecting
all released Tor instances since 0.2.1.5-alpha. Using this
vulnerability, an attacker could cause Tor instances to consume a huge
...This is the description I posted in the changelog:
```
TROVE-2020-002 is a vulnerability affecting
all released Tor instances since 0.2.1.5-alpha. Using this
vulnerability, an attacker could cause Tor instances to consume a huge
amount of CPU, disrupting their operations for several seconds or
minutes. This attack could be launched by anybody against a relay, or
by a directory cache against any client that had connected to it. The
attacker could launch this attack as much as they wanted, thereby
disrupting service or creating patterns that could aid in traffic
analysis. This issue was found by OSS-Fuzz, and is also tracked
as CVE-2020-10592.
```
I will post a more detailed analysis in a week or so.
This issue is fixed in today's Tor releases: 0.3.5.10, 0.4.1.9, 0.4.2.7, and 0.4.3.3-alpha.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33124Controller circuits don't pass the SOCKS request address in relay begin cells2021-07-09T17:22:51ZoparaController circuits don't pass the SOCKS request address in relay begin cellsIf a stream is attached to a circuit with purpose `CIRCUIT_PURPOSE_CONTROLLER`, a RELAY_BEGIN cell will be sent with an empty address. This is because of a bug in `connection_ap_handshake_send_begin()`.
```
tor_snprintf(payload,RELAY_PA...If a stream is attached to a circuit with purpose `CIRCUIT_PURPOSE_CONTROLLER`, a RELAY_BEGIN cell will be sent with an empty address. This is because of a bug in `connection_ap_handshake_send_begin()`.
```
tor_snprintf(payload,RELAY_PAYLOAD_SIZE, "%s:%d",
(circ->base_.purpose == CIRCUIT_PURPOSE_C_GENERAL) ?
ap_conn->socks_request->address : "",
ap_conn->socks_request->port);
```
The function seems to assume that if it's not a general purpose circuit, then it is a rendezvous circuit. This was added in [commit 5b6099e8](https://github.com/torproject/tor/commit/5b6099e8#diff-0798d3d17392dc5c15f3f58a5fc6b29aR946-R957).
There is a similar error in a logging statement in `link_apconn_to_circ()` which logs that a controller circuit is to a "hidden service", even if the circuit is actually to an exit.
```
log_info(LD_APP, "Looks like completed circuit to %s %s allow "
"optimistic data for connection to %s",
circ->base_.purpose == CIRCUIT_PURPOSE_C_GENERAL ?
/* node_describe() does the right thing if exitnode is NULL */
safe_str_client(node_describe(exitnode)) :
"hidden service",
apconn->may_use_optimistic_data ? "does" : "doesn't",
safe_str_client(apconn->socks_request->address));
```
And another example is in `connection_ap_expire_beginning()` which logs the warning:
```
[warn] connection_ap_expire_beginning(): Bug: circuit->purpose == CIRCUIT_PURPOSE_C_GENERAL failed. The purpose on the circuit was Circuit made by controller; it was in state open, path_state new. (on Tor 0.4.2.5 )
```
The relay which receives the RELAY_BEGIN cell will then make a dns request for the address "". Libevent will eventually give up after 3 tries (`global_timeout.tv_sec = 5` seconds per try).
```
Feb 01 01:11:41.369 [info] launch_resolve(): Launching eventdns request for ""
Feb 01 01:11:41.369 [info] evdns_log_cb(): eventdns: Resolve requested.
...
Feb 01 01:11:56.378 [info] eventdns: Giving up on request 0x5565c825ac80; tx_count==3
```
Back at the tor client, the streams detach (reason=timeout, remote_reason=none) after some time, then the controller circuits close a few seconds later (a total of 25 seconds after the streams were first attached) with:
```
[info] circuit_mark_for_close_(): Circuit 2262666673 (id: 15) marked for close at src/core/or/circuituse.c:1507 (orig reason: 9, new reason: 0)
```
Finally a SOCKS error code `0x5b` is returned to the application after some long amount of time.
In summary, the main problems are:
(1) Tor has checks for only `CIRCUIT_PURPOSE_C_GENERAL` when it should be checking for other circuit purposes like `CIRCUIT_PURPOSE_CONTROLLER`.
(2) Tor attempts to resolve the address of an empty string.
(3) (Maybe?) It takes a long time before the application is notified that the SOCKS connection was unsuccessful.
Thanks to arma for help debugging this.Neel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33129Tor node that is not part of the consensus should not be used as rendezvous p...2022-10-24T20:53:07ZcypherpunksTor node that is not part of the consensus should not be used as rendezvous point with the onion serviceAccording to this article attacker is able to to chose a server that is running Tor but is not part of the Tor network as an rendezvous point with the onion service so that he can discover in to which family onion service`s guard node be...According to this article attacker is able to to chose a server that is running Tor but is not part of the Tor network as an rendezvous point with the onion service so that he can discover in to which family onion service`s guard node belongs and than use that information to ddos Tor nodes in that family so that onion service drops that guard node and instead chose his Tor node as a guard node.
https://www.hackerfactor.com/blog/index.php?/archives/868-Deanonymizing-Tor-Circuits.htmlhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33131Bug: buf->datalen >= 0x7fffffff2021-01-28T18:01:38ZcypherpunksBug: buf->datalen >= 0x7fffffffWith
```
BandwidthRate
```
set greater than 2147483646 bytes, for example Config line:
```
BandwidthRate 2147483647
#same as
BandwidthRate 2 GBytes
```
no streams complete in my relay and this Bug message appears:
```
Feb 02 06:...With
```
BandwidthRate
```
set greater than 2147483646 bytes, for example Config line:
```
BandwidthRate 2147483647
#same as
BandwidthRate 2 GBytes
```
no streams complete in my relay and this Bug message appears:
```
Feb 02 06:32:37.000 [warn] {BUG} tor_bug_occurred_(): Bug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(ASSERT_PREDICT
_UNLIKELY_(buf->datalen >= 0x7fffffff - at_most)) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.5 )
Feb 02 06:32:37.000 [warn] {BUG} Bug: Tor 0.4.2.5: Non-fatal assertion !(ASSERT_PREDICT_UNLIKELY_(buf->datalen >= 0x7fffffff - at_mo
st)) failed in buf_read_from_tls at buffers_tls.c:73. (Stack trace not available) (on Tor 0.4.2.5 )
```
Looks like some INT_MAX buffer count trouble to me at least.
```
# BandwidthRate BandwidthRate __N__ bytes|KBytes|MBytes|GBytes|TBytes|KBits|MBits|GBits|TBits
# A token bucket limits the average incoming bandwidth usage on this node
# to the specified number of bytes per second, and the average outgoing
# bandwidth usage to that same value. If you want to run a relay in the
# public network, this needs to be _at the very least_ 75 KBytes for a
# relay (that is, 600 kbits) or 50 KBytes for a bridge (400 kbits) -- but of
# course, more is better; we recommend at least 250 KBytes (2 mbits) if
# possible. (Default: 1 GByte) +
# +
# Note that this option, and other bandwidth-limiting options, apply to TCP
# data only: They do not count TCP headers or DNS traffic. +
# +
# With this option, and in other options that take arguments in bytes,
# KBytes, and so on, other formats are also supported. Notably, "KBytes" can
# also be written as "kilobytes" or "kb"; "MBytes" can be written as
# "megabytes" or "MB"; "kbits" can be written as "kilobits"; and so forth.
# Tor also accepts "byte" and "bit" in the singular.
# The prefixes "tera" and "T" are also recognized.
# If no units are given, we default to bytes.
# To avoid confusion, we recommend writing "bytes" or "bits" explicitly,
# since it's easy to forget that "B" means bytes, not bits.
```Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33137Resolve TROVE-2020-003: crash adding bad ed25519 HSv3 private key from contro...2021-08-23T15:12:43ZNick MathewsonResolve TROVE-2020-003: crash adding bad ed25519 HSv3 private key from controllerThis bug is an assertion failure that can only be triggered by an attacker with access to the user's controlport: if they use ADD_ONION to pass in an invalid ed25519 key, then Tor will exit.
Here is asn's analysis of the issue:
```
===...This bug is an assertion failure that can only be triggered by an attacker with access to the user's controlport: if they use ADD_ONION to pass in an invalid ed25519 key, then Tor will exit.
Here is asn's analysis of the issue:
```
================================================================================
Analysis of TROVE-2020-003
================================================================================
Summary
================================================================================
The issue at hand is that hs_build_address() can crash with an assert failure
if called with an "invalid" ed25519 public key as its 'key' argument. Usually
that function is only called with valid public keys, but after the introduction
of the ADD_ONION control port feature and the hs_service_add_ephemeral()
function, it can now be called with an invalid public key and cause an assert
crash.
Tor considers an ed25519 public key to be "invalid" when it has a torsion
component (see [TORSION-REFS] in rend-spec-v3.txt) so that phishing attackers
cannot generate equivalent onion addresses for a normal onion address. This is
a validation step that is usually not required for normal ed25519-based
protocols, but it's actually necessary for the security of onion addresses or
in any other place where keys or signatures are used as identifiers and
security relies on their uniqueness.
The validating function is ed25519_validate_pubkey() and it's currently used in
two cases:
1) for onion address validation, so that attackers cannot create equivalent
sets of onion addresses
2) when dirauths validate relay ed25519 keys, for reasons unclear to me
(perhaps this check is not needed)
Impact
================================================================================
The impact of this bug is a local denial-of-service attack to Tor through an
assert-failure.
The particular ADD_ONION attack vector can only be triggered by an attacker who
has access to the control port which assumes a local attacker. Also an attacker
who has access to the control port can do various other modifications to Tor
that will result in loss of security. This is the reason this bug is marked as
'low' severity.
Fix
================================================================================
Given that ed25519 public key validity checks are usually not needed and (so
far) they are only necessary for onion addesses in the Tor protocol, we decided
to fix this specific bug instance without modifying the rest of the codebase
(see below for other fix approaches).
In our minimal fix we check that the pubkey in hs_service_add_ephemeral() is
valid and error out otherwise.
This will fix the issue in the current codebase but it doesn't solve it in the
future if a new feature comes in which tried to do something like ADD_ONION, or
if a new feature comes out which tries to use ed25519 in a non-standard and
dangerous way.
Considerations for the future
================================================================================
ed25519 signature and public key malleability is a complex topic that protocol
designers must be aware of when using ed25519 in non-standard ways in the
protocol. In our case, we got bitten by passing ed25519 *private* keys around,
but there are other theoretical cases where this can bite us. Hence, protocol
designers and reviewers who work with ed25519 should be aware of such threats
when creating new protocols.
In the future, we should consider moving to signature schemes based on
Ristretto (or others) which do not need additional optional key validation.
Other fix approaches
================================================================================
Here are some other fix approaches I ended up not taking:
1) Check validity in ed25519_public_key_generate()
One possible fix would be to patch ed25519_public_key_generate() so that it
doesn't return "invalid" public keys. However, ed25519_validate_pubkey() is
not cheap (it does a scalar mult and a point compression) and it's almost
never needed, so we would make this validation optional and only enable it
when it's needed.
The problem here is that this is gonna complicate the interface of
ed25519_public_key_generate() for everyone, and also it almost never makes
sense to use the validation feature so developers will always be confused on
whether they should use it or not.
For reference, see how ed25519-dalek has the optional verify_strict()
function which is not clear when should be used by developers [0].
2) Enforce validity in ed25519_public_key_generate()
Another approach would be to enforce that public keys created with
ed25519_public_key_generate() are valid by clamping the secret key before
producing the public key. Clamping is not expensive so this would not be too
bad for performance.
I actually tried to implement this but the blinded public key tests
immediately broke: it seems like there are issues with clamping and
hierarchical key derivation that would not allow us to do this [1].
Furthermore, doing this would change our ed25519 behavior in a
non-standard way.
3) Fix this particular HSv3 bug (in hs_build_address())
Another fix would be to patch just hs_build_address() and make sure that it
fails if the resulting address is not valid.
The problem here is that this will complicate the interface of
hs_build_address() which is normally called with well behaving keys and is
only called with a bad key in the case of ADD_ONION. The callers would have
to check the retval for no gain, and the end result would be equal to the fix
approach we took.
Further investigation
================================================================================
As part of our investigation for this bug, we did the following additional digging:
- Audited all the places where hs_build_address() is called
We audited all the places where hs_build_address() is called to see if any of
them might be called with invalid pubkeys but it seems like the only
vulnerable place is the bug above related to ADD_ONION.
All other calls of hs_build_address() are either using the self-generated
service public keys, or in the client case getting them directly from the HS
identifier where the public key has been explicitly checked for validity
during the SOCKS phase in connection_ap_handshake_rewrite_and_attach() with
parse_extended_hostname().
XXX Do you want me to make a branch with the various call sites annotated
with why I think they are innocent?
- Audited all the places where we get ed25519 private keys from foreign sources
Tor mostly loads self-generated ed25519 private keys from files, or generates
them itself (e.g. in the case of blinded keys). The only place where an
ed25519 private key is loaded from a non-local source is the bug in question
above using ADD_ONION.
- Audited all the places where we get x25519 private keys from foreign sources
In general, x25519 keys should not need validation like we do for ed25519
keys [2]. Still, we decided to take a look at whether we load any x25519 private
keys from non-local sources as part of our investigation.
Tor usually loads pre-generated x25519 keys from file, or generates them
itself.
However, in the HSv3 client authorization feature we can get an x25519
privkey from the control port through the ONION_CLIENT_AUTH_ADD command (in
handle_control_onion_client_auth_add()). However, we never convert that key
to a pubkey, as it always lives in hs_client_service_authorization_t as a
secret key. Also, when we actually do use that secret key in
build_descriptor_cookie_keys() the x25519 module is responsible for doing the
necessary tweaks to make it well formed (see how curve25519_donna() does the
necessary bit transformations on the 'secret' key).
[0]: https://github.com/dalek-cryptography/ed25519-dalek#the-verify_strict-function
[1]: https://moderncrypto.org/mail-archive/curves/2017/000858.html
[2]: https://lists.torproject.org/pipermail/tor-dev/2017-April/012213.html
```Tor: 0.4.3.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/33139New Identity should remove v3 client auth ephemeral keys2021-08-23T15:12:44ZMark SmithNew Identity should remove v3 client auth ephemeral keysAs discussed in ticket:19757#comment:31 through comment 34, tor should remove all of the ephemeral v3 client authorization keys when a NEWNYM signal is received (new identity).As discussed in ticket:19757#comment:31 through comment 34, tor should remove all of the ephemeral v3 client authorization keys when a NEWNYM signal is received (new identity).Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33140Clusterfuzz environment flags reused for dependencies2020-07-29T14:28:29ZcypherpunksClusterfuzz environment flags reused for dependenciesThe build script for tor at oss-fuzz currently reuses clusterfuzz environment variables to compile dependencies. This has consequences when the dependencies themselves are upstream projects at oss-fuzz. The build environment sets the fol...The build script for tor at oss-fuzz currently reuses clusterfuzz environment variables to compile dependencies. This has consequences when the dependencies themselves are upstream projects at oss-fuzz. The build environment sets the following flags to enable fuzzing of a target project:
```
CC=clang
CXX=clang++
CFLAGS=-O1 -fno-omit-frame-pointer -gline-tables-only -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION -fsanitize=address -fsanitize-address-use-after-scope -fsanitize=fuzzer-no-link
CXXFLAGS=-O1 -fno-omit-frame-pointer -gline-tables-only -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION -fsanitize=address -fsanitize-address-use-after-scope -fsanitize=fuzzer-no-link -stdlib=libc++
```
In the case of zlib: Using the environment flags above as-is results in activating oss-fuzz instrumentation. Eventually resulting in ambiguously placed `undefined symbol __sancov_lowest_stack` because stack depth tracing was not instrumented properly. Which leads to a rabbit-hole of why are we fixing instrumenting fuzzers in tor's dependencies?
Now Openssl also has an upstream clusterfuzz instance and so leaving the environment flags as-is also results in instrumenting openssl for oss-fuzz.
This sounds wrong. If we're fuzzing tor then why are we also instrumenting dependencies for clusterfuzz? It looks like the dependencies **should** override these flags when built to avoid conflicts.
When the flags are overridden to build debug dependencies, followed by building tor's fuzzers as usual, `check_build tor` passes all tests.https://gitlab.torproject.org/tpo/core/tor/-/issues/33148hs-v3: Clean cached descriptor(s) on ONION_CLIENT_AUTH_REMOVE2020-06-27T13:48:22ZDavid Gouletdgoulet@torproject.orghs-v3: Clean cached descriptor(s) on ONION_CLIENT_AUTH_REMOVEWhen a client authorization is removed with the control command `ONION_CLIENT_AUTH_REMOVE`, we should also remove the associated descriptor from the cache else the .onion is still accessible even though the credentials have been removed....When a client authorization is removed with the control command `ONION_CLIENT_AUTH_REMOVE`, we should also remove the associated descriptor from the cache else the .onion is still accessible even though the credentials have been removed.
Found by mcs/brade/acat during testing: https://trac.torproject.org/projects/tor/ticket/19757#comment:31Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33156DoS subsystem should compare IPv6 /642022-10-11T23:41:45ZteorDoS subsystem should compare IPv6 /64s7r writes:
> Our internal DoS defense subsystem should also treat prefixes instead of
> addresses, because right now with a client with a /64 public IPv6 prefix
> assigned to it I could hammer via IPv6 guards without triggering the DoS...s7r writes:
> Our internal DoS defense subsystem should also treat prefixes instead of
> addresses, because right now with a client with a /64 public IPv6 prefix
> assigned to it I could hammer via IPv6 guards without triggering the DoS
> defense.
https://lists.torproject.org/pipermail/tor-dev/2020-February/014144.html
We could make this change by:
* only putting the first /64 of each IPv6 address in the filter list, and
* only checking the first /64 of each new IPv6 connectionhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33159Write a proposal for monitoring IPv62020-06-27T13:48:22ZteorWrite a proposal for monitoring IPv6For sponsor 55, I need to write a proposal that covers these objectives:
* O1.4 - Measure the number of Tor relays that support IPv6 reachability checks (legacy/trac#33051)
* O1.5 - Measure the number of connections, and consumed bandwid...For sponsor 55, I need to write a proposal that covers these objectives:
* O1.4 - Measure the number of Tor relays that support IPv6 reachability checks (legacy/trac#33051)
* O1.5 - Measure the number of connections, and consumed bandwidth, using IPv4 and IPv6 (legacy/trac#33052)
My current thinking is that:
* tor should log the number and consensus weight of relays that support IPv6 reachability checks, because we will need those numbers during testing
* these numbers are available in the consensus
Here's what the proposal requires:
* calculate relay IPv6 reachability numbers a few times during the project (we may as well use the tor logs)
* collect IPv6 connection and bandwidth statistics on tor relays
* calculate the IPv6 connection and bandwidth amounts a few times during the project
Here are some other useful things we might do:
* split the collected IPv6 statistics by client/relay
* calculate the guard-but-not-exit relays that support IPv6 client connections
* log IPv6 statistics in tor's heartbeat logs (we can't use these logs for our project reports, because they only show the local relay's statistics)
* calculate IPv6 reachability relay count and consensus weight on consensus-health
* add a pseudo-flag for relay IPv6 reachability support in Relay Search
* add metrics graphs that shows our progress on
* IPv6 reachability
* client IPv6 support on relays
* IPv6 connections and bandwidth
We definitely won't have time to do all of these optional things, so we should priorise, once the essential work is done.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33161Latest version for buster on Raspberry Pi fails to start2020-07-29T14:27:45ZTracLatest version for buster on Raspberry Pi fails to startUpgraded my raspberry pi running Rasbian to the latest 'buster' release and tor will not start up. Could not find the error I see in the logs listed anywhere else, so raising this ticket:
my sources file looks like this
```
deb http://...Upgraded my raspberry pi running Rasbian to the latest 'buster' release and tor will not start up. Could not find the error I see in the logs listed anywhere else, so raising this ticket:
my sources file looks like this
```
deb http://raspbian.raspberrypi.org/raspbian/ buster main contrib non-free rpi
deb http://deb.torproject.org/torproject.org buster main
```
After apt-get update and apt-get upgrade tor will not start.
```
Feb 5 14:47:42 raspberrypi systemd[1]: Starting Anonymizing overlay network for TCP...
Feb 5 14:47:42 raspberrypi systemd[1]: tor@default.service: Control process exited, code=killed, status=4/ILL
Feb 5 14:47:42 raspberrypi systemd[1]: tor@default.service: Failed with result 'signal'.
Feb 5 14:47:42 raspberrypi systemd[1]: Failed to start Anonymizing overlay network for TCP.
Feb 5 14:47:42 raspberrypi systemd[1]: tor@default.service: Service RestartSec=100ms expired, scheduling restart.
Feb 5 14:47:42 raspberrypi systemd[1]: tor@default.service: Scheduled restart job, restart counter is at 1.
Feb 5 14:47:42 raspberrypi systemd[1]: Stopped Anonymizing overlay network for TCP.
Feb 5 14:47:42 raspberrypi systemd[1]: Starting Anonymizing overlay network for TCP...
Feb 5 14:47:42 raspberrypi systemd[1]: tor@default.service: Control process exited, code=killed, status=4/ILL
Feb 5 14:47:42 raspberrypi systemd[1]: tor@default.service: Failed with result 'signal'.
Feb 5 14:47:42 raspberrypi systemd[1]: Failed to start Anonymizing overlay network for TCP.
Feb 5 14:47:43 raspberrypi systemd[1]: tor@default.service: Service RestartSec=100ms expired, scheduling restart.
Feb 5 14:47:43 raspberrypi systemd[1]: tor@default.service: Scheduled restart job, restart counter is at 2.
Feb 5 14:47:43 raspberrypi systemd[1]: Stopped Anonymizing overlay network for TCP.
Feb 5 14:47:43 raspberrypi systemd[1]: Starting Anonymizing overlay network for TCP...
Feb 5 14:47:43 raspberrypi systemd[1]: tor@default.service: Control process exited, code=killed, status=4/ILL
Feb 5 14:47:43 raspberrypi systemd[1]: tor@default.service: Failed with result 'signal'.
Feb 5 14:47:43 raspberrypi systemd[1]: Failed to start Anonymizing overlay network for TCP.
Feb 5 14:47:43 raspberrypi systemd[1]: tor@default.service: Service RestartSec=100ms expired, scheduling restart.
Feb 5 14:47:43 raspberrypi systemd[1]: tor@default.service: Scheduled restart job, restart counter is at 3.
Feb 5 14:47:43 raspberrypi systemd[1]: Stopped Anonymizing overlay network for TCP.
Feb 5 14:47:43 raspberrypi systemd[1]: Starting Anonymizing overlay network for TCP...
Feb 5 14:47:43 raspberrypi systemd[1]: tor@default.service: Control process exited, code=killed, status=4/ILL
Feb 5 14:47:43 raspberrypi systemd[1]: tor@default.service: Failed with result 'signal'.
Feb 5 14:47:43 raspberrypi systemd[1]: Failed to start Anonymizing overlay network for TCP.
Feb 5 14:47:44 raspberrypi systemd[1]: tor@default.service: Service RestartSec=100ms expired, scheduling restart.
Feb 5 14:47:44 raspberrypi systemd[1]: tor@default.service: Scheduled restart job, restart counter is at 4.
Feb 5 14:47:44 raspberrypi systemd[1]: Stopped Anonymizing overlay network for TCP.
Feb 5 14:47:44 raspberrypi systemd[1]: Starting Anonymizing overlay network for TCP...
Feb 5 14:47:44 raspberrypi systemd[1]: tor@default.service: Control process exited, code=killed, status=4/ILL
Feb 5 14:47:44 raspberrypi systemd[1]: tor@default.service: Failed with result 'signal'.
Feb 5 14:47:44 raspberrypi systemd[1]: Failed to start Anonymizing overlay network for TCP.
Feb 5 14:47:44 raspberrypi systemd[1]: tor@default.service: Service RestartSec=100ms expired, scheduling restart.
Feb 5 14:47:44 raspberrypi systemd[1]: tor@default.service: Scheduled restart job, restart counter is at 5.
Feb 5 14:47:44 raspberrypi systemd[1]: Stopped Anonymizing overlay network for TCP.
Feb 5 14:47:44 raspberrypi systemd[1]: tor@default.service: Start request repeated too quickly.
Feb 5 14:47:44 raspberrypi systemd[1]: tor@default.service: Failed with result 'signal'.
Feb 5 14:47:44 raspberrypi systemd[1]: Failed to start Anonymizing overlay network for TCP.
```
Version
```
pi@raspberrypi:~ $ apt-cache policy tor
tor:
Installed: 0.4.2.6-1~d10.buster+1
Candidate: 0.4.2.6-1~d10.buster+1
Version table:
*** 0.4.2.6-1~d10.buster+1 500
500 http://deb.torproject.org/torproject.org buster/main armhf Packages
100 /var/lib/dpkg/status
0.3.5.8-1 500
500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages
```
**Trac**:
**Username**: tescophilhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33164Update torspec reindex.py for Python 32020-06-27T13:48:22ZteorUpdate torspec reindex.py for Python 3We need to update torspec's proposals/reindex.py for Python 3.
As a consequence, proposal must be encoded in UTF-8.We need to update torspec's proposals/reindex.py for Python 3.
As a consequence, proposal must be encoded in UTF-8.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33188Tor Manual: Alphabetize Server and Directory Server Options2021-07-22T16:18:20ZTracTor Manual: Alphabetize Server and Directory Server OptionsAlphabetize options in the Server Options and Directory Server Options
**Trac**:
**Username**: swatiAlphabetize options in the Server Options and Directory Server Options
**Trac**:
**Username**: swati