Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:52:47Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33804Defer "PreferIPv6 by default" to 0.4.42020-06-13T15:52:47ZteorDefer "PreferIPv6 by default" to 0.4.4In #32637, we made clients default to "PreferIPv6" on SOCKSPorts (and other client ports).
But in #33796, we discovered that this change broke torsocks.
We want to defer this change to 0.4.4, so tor can implement IPv4-only and IPv6-onl...In #32637, we made clients default to "PreferIPv6" on SOCKSPorts (and other client ports).
But in #33796, we discovered that this change broke torsocks.
We want to defer this change to 0.4.4, so tor can implement IPv4-only and IPv6-only resolves for torsocks.
Since #32637, we have also merged:
* #33608, which removes a forced PreferIPv6 for non-SOCKSPorts
* #32994, which puts the PreferIPv6 default in port_parse_config(), rather than in 2 different places in the code
So it should be very easy to change the default for PreferIPv6.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33668--disable-module-relay yields to a Bug:2020-06-13T15:52:24Ztoralf--disable-module-relay yields to a Bug:At a hardened Gentoo Linux the configure option yields to a
```
# tor --verify-config
Mar 19 19:44:35.839 [notice] Tor 0.4.3.3-alpha running on Linux with Libevent 2.1.8-stable, OpenSSL LibreSSL 3.0.2, Zlib 1.2.11, Liblzma 5.2.4, and L...At a hardened Gentoo Linux the configure option yields to a
```
# tor --verify-config
Mar 19 19:44:35.839 [notice] Tor 0.4.3.3-alpha running on Linux with Libevent 2.1.8-stable, OpenSSL LibreSSL 3.0.2, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd N/A.
Mar 19 19:44:35.840 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Mar 19 19:44:35.840 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Mar 19 19:44:35.840 [notice] Read configuration file "/etc/tor/torrc".
Mar 19 19:44:35.843 [err] tor_assertion_failed_(): Bug: src/app/config/config.c:1473: options_switch_id: Assertion have_low_ports != -1 failed; aborting. (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.844 [err] Bug: Tor 0.4.3.3-alpha: Assertion have_low_ports != -1 failed in options_switch_id at src/app/config/config.c:1473: . Stack trace: (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(log_backtrace_impl+0x59) [0x5564677d3ab9] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(tor_assertion_failed_+0x150) [0x5564677cecb0] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(set_options+0x404) [0x5564677535d4] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(+0x1648a0) [0x5564677548a0] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(options_init_from_string+0x119) [0x556467754af9] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(options_init_from_torrc+0x359) [0x5564677550f9] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(tor_init+0x1c7) [0x55646764ade7] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: tor(tor_run_main+0x71) [0x55646764b4e1] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: tor(tor_main+0x46) [0x55646764a006] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: tor(main+0x19) [0x556467649bd9] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: /lib64/libc.so.6(__libc_start_main+0xeb) [0x7ff9817b8f1b] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: tor(_start+0x2a) [0x556467649c2a] (on Tor 0.4.3.3-alpha )
Aborted
```
The same tarball at the same system works fine with that option being enabled.
The config is
```
cat /etc/tor/torrc
User tor
PIDFile /var/run/tor/tor.pid
Log notice file /tmp/notice.log
DataDirectory /var/lib/tor/data
CookieAuthentication 1
ControlPort 9051
SocksPort 9050
SandBox 1
```Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/33646Wrong list of enabled modules2020-06-13T15:52:22ZTracWrong list of enabled modulesWhen I build tor 0.4.3.3-alpha with
`./autogen.sh && ./configure --disable-unittests --disable-module-dirauth && make`
line, I see following text:
```
Modules
relay (--disable-module-relay): yes
dirauth...When I build tor 0.4.3.3-alpha with
`./autogen.sh && ./configure --disable-unittests --disable-module-dirauth && make`
line, I see following text:
```
Modules
relay (--disable-module-relay): yes
dirauth (--disable-module-dirauth): yes
dircache (--disable-module-dircache): yes
```
Which is wrong, since I have enabled relay and disabled dirauth.
Looks like problem is located in commit [9c33d36113447d38decd22d177e62fb225826d78](https://gitweb.torproject.org/tor.git/commit/?id=9c33d36113447d38decd22d177e62fb225826d78).
Related: #32230.
Please recheck.
**Trac**:
**Username**: VortTor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33545assertion failure when "all zero" client auth key provided2020-06-13T15:53:04ZMark Smithassertion failure when "all zero" client auth key providedWhile doing some Tor Browser testing for Sponsor 27, I experienced the following after I intentionally used an incorrect client auth key for a v3 onion service:
```
... [err] tor_assertion_failed_: Bug: src/feature/hs/hs_descriptor.c:142...While doing some Tor Browser testing for Sponsor 27, I experienced the following after I intentionally used an incorrect client auth key for a v3 onion service:
```
... [err] tor_assertion_failed_: Bug: src/feature/hs/hs_descriptor.c:1423: decrypt_descriptor_cookie: Assertion !fast_mem_is_zero((char *) client_auth_sk, sizeof(*client_auth_sk)) failed; aborting. (on Tor 0.4.4.0-alpha-dev 1da0b05a5cace6ed)
```
As it turns out, I happened to enter a key that is consists entirely of zero bits. This is an unusual thing to do, but I do not think tor should exit.
Steps to reproduce in Tor Browser:
1. Try to load an http or https page for a v3 onion service that requires client authentication, e.g., dgoulet's test server.
2. Enter 56 'A's when prompted for a client auth key.
Result: tor exits due to the assertion failure. Behind the scenes, the browser installs the key via a control port command like the following:
```
onion_client_auth_add <onion-addr> x25519:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
```
and then tries to access the onion service again (page reload).Tor: 0.4.3.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/33458Assertion desc failed in hs_client_close_intro_circuits_from_desc at src/feat...2020-06-13T15:51:51ZGeorge KadianakisAssertion desc failed in hs_client_close_intro_circuits_from_desc at src/feature/hs/hs_client.c: 2413Just got this assert failure in my TBB. I had a v3 onion open, and long ago I visited a client-auth onion that I didn't manage to decrypt so it lingered in my cache with `->desc` set to `NULL`.
```
Feb 26 14:17:31.000 [err] tor_asserti...Just got this assert failure in my TBB. I had a v3 onion open, and long ago I visited a client-auth onion that I didn't manage to decrypt so it lingered in my cache with `->desc` set to `NULL`.
```
Feb 26 14:17:31.000 [err] tor_assertion_failed_(): Bug: src/feature/hs/hs_client.c:2413: hs_client_close_intro_circuits_from_desc: Assertion desc failed; aborting. (on T
or 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: Tor 0.4.3.2-alpha (git-dcbf6611d9980953): Assertion desc failed in hs_client_close_intro_circuits_from_desc at src/feature/hs/hs_client.c:
2413: . Stack trace: (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(log_backtrace_impl+0x56) [0x5623c8fe6e96] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(tor_assertion_failed_+0x147) [0x5623c8fe1f97] (on Tor 0.4.3.2-alpha dcbf6611d9980
953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(hs_client_close_intro_circuits_from_desc+0xb6) [0x5623c8ee7c76] (on Tor 0.4.3.2-a
lpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(hs_cache_clean_as_client+0xf2) [0x5623c8edfbd2] (on Tor 0.4.3.2-alpha dcbf6611d99
80953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(+0x6ebbc) [0x5623c8e3fbbc] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(+0x73487) [0x5623c8e44487] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: ./TorBrowser/Tor/libevent-2.1.so.6(+0x22565) [0x7f3c28b8a565] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: ./TorBrowser/Tor/libevent-2.1.so.6(event_base_loop+0x517) [0x7f3c28b8af27] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(do_main_loop+0xdb) [0x5623c8e4372b] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(tor_run_main+0x10b5) [0x5623c8e309f5] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(tor_main+0x3a) [0x5623c8e2e19a] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(main+0x19) [0x5623c8e2dd39] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f3c28207bbb] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
Feb 26 14:17:31.000 [err] Bug: /home/f/tor-browser_en-US/Browser/TorBrowser/Tor/tor(+0x5cd89) [0x5623c8e2dd89] (on Tor 0.4.3.2-alpha dcbf6611d9980953)
```Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33148hs-v3: Clean cached descriptor(s) on ONION_CLIENT_AUTH_REMOVE2020-06-13T15:50:40ZDavid 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/legacy/trac/-/issues/33137Resolve TROVE-2020-003: crash adding bad ed25519 HSv3 private key from contro...2020-06-13T15:50:39ZNick 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/legacy/trac/-/issues/33120Resolve TROVE-2020-0022020-06-13T15:50:35ZNick 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/legacy/trac/-/issues/33119Resolve TROVE-2020-0012020-06-13T15:50:35ZNick MathewsonResolve TROVE-2020-001Tor: 0.4.4.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33103LeakSanitizer is kicking in with tor being on 39c5e1b84994c2f226a8530b930f215...2020-06-13T15:50:33ZGeorg 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/legacy/trac/-/issues/33039Memory leaks in handle_control_getconf2020-06-13T15:50:12ZNick MathewsonMemory leaks in handle_control_getconfFound while investigating #33006:
```
=================================================================
==180005==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7fb54c5cdc5...Found while investigating #33006:
```
=================================================================
==180005==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7fb54c5cdc58 in __interceptor_malloc (/lib64/libasan.so.5+0x10dc58)
#1 0x55a4af274f3a in tor_malloc_ src/lib/malloc/malloc.c:45
#2 0x55a4af274fd0 in tor_malloc_zero_ src/lib/malloc/malloc.c:71
#3 0x55a4af2371ca in config_line_append src/lib/encoding/confline.c:40
#4 0x55a4aeffaec7 in control_reply_add_one_kv src/feature/control/control_proto.c:345
#5 0x55a4aefdd2ae in handle_control_getconf src/feature/control/control_cmd.c:307
#6 0x55a4aefe54b2 in handle_single_control_command src/feature/control/control_cmd.c:2376
#7 0x55a4aefe54b2 in handle_control_command src/feature/control/control_cmd.c:2407
#8 0x55a4aefd6e01 in connection_control_process_inbuf src/feature/control/control.c:508
#9 0x55a4aeee0e01 in connection_handle_read_impl src/core/mainloop/connection.c:3737
#10 0x55a4aeee0e01 in connection_handle_read src/core/mainloop/connection.c:3777
#11 0x55a4aeeecf00 in conn_read_callback src/core/mainloop/mainloop.c:892
#12 0x7fb54c32abb6 (/lib64/libevent-2.1.so.6+0x25bb6)
Indirect leak of 26 byte(s) in 1 object(s) allocated from:
#0 0x7fb54c55652d in strdup (/lib64/libasan.so.5+0x9652d)
#1 0x55a4af2751d0 in tor_strdup_ src/lib/malloc/malloc.c:165
#2 0x55a4af2371d5 in config_line_append src/lib/encoding/confline.c:41
#3 0x55a4aeffaec7 in control_reply_add_one_kv src/feature/control/control_proto.c:345
#4 0x55a4aefdd2ae in handle_control_getconf src/feature/control/control_cmd.c:307
#5 0x55a4aefe54b2 in handle_single_control_command src/feature/control/control_cmd.c:2376
#6 0x55a4aefe54b2 in handle_control_command src/feature/control/control_cmd.c:2407
#7 0x55a4aefd6e01 in connection_control_process_inbuf src/feature/control/control.c:508
#8 0x55a4aeee0e01 in connection_handle_read_impl src/core/mainloop/connection.c:3737
#9 0x55a4aeee0e01 in connection_handle_read src/core/mainloop/connection.c:3777
#10 0x55a4aeeecf00 in conn_read_callback src/core/mainloop/mainloop.c:892
#11 0x7fb54c32abb6 (/lib64/libevent-2.1.so.6+0x25bb6)
Indirect leak of 7 byte(s) in 1 object(s) allocated from:
#0 0x7fb54c55652d in strdup (/lib64/libasan.so.5+0x9652d)
#1 0x55a4af2751d0 in tor_strdup_ src/lib/malloc/malloc.c:165
#2 0x55a4af2371f5 in config_line_append src/lib/encoding/confline.c:42
#3 0x55a4aeffaec7 in control_reply_add_one_kv src/feature/control/control_proto.c:345
#4 0x55a4aefdd2ae in handle_control_getconf src/feature/control/control_cmd.c:307
#5 0x55a4aefe54b2 in handle_single_control_command src/feature/control/control_cmd.c:2376
#6 0x55a4aefe54b2 in handle_control_command src/feature/control/control_cmd.c:2407
#7 0x55a4aefd6e01 in connection_control_process_inbuf src/feature/control/control.c:508
#8 0x55a4aeee0e01 in connection_handle_read_impl src/core/mainloop/connection.c:3737
#9 0x55a4aeee0e01 in connection_handle_read src/core/mainloop/connection.c:3777
#10 0x55a4aeeecf00 in conn_read_callback src/core/mainloop/mainloop.c:892
#11 0x7fb54c32abb6 (/lib64/libevent-2.1.so.6+0x25bb6)
SUMMARY: AddressSanitizer: 65 byte(s) leaked in 3 allocation(s).
Exit code was 1
success (15.21s)
```Tor: 0.4.3.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/33029dir-auth: Dir auths should resume sending 503's but never to relays or other ...2020-11-13T13:39:33ZDavid Gouletdgoulet@torproject.orgdir-auth: Dir auths should resume sending 503's but never to relays or other dir authsThis is a child ticket from #33018.
The idea here is that even if we hit the global write limit (bw), we should not return 503 code but rather answer another directory authority.
Dirauth _must_ be able to talk to each other at all time...This is a child ticket from #33018.
The idea here is that even if we hit the global write limit (bw), we should not return 503 code but rather answer another directory authority.
Dirauth _must_ be able to talk to each other at all time regardless of the bandwidth state.
Setting 043 milestone because this should be considered a bug and could even be considered for backport since dirauth are suffering from this at the moment.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32984Revert #32883 for now and apply #32778 (so nt services can work in 0.4.3)2020-06-13T15:50:01ZNick MathewsonRevert #32883 for now and apply #32778 (so nt services can work in 0.4.3)In theory, #32883 was a better solution for the problem that #32778 was supposed to solve. In practice, it seems to break nt services on master. We should revert it for now until we have time to debug it in a later alpha series.In theory, #32883 was a better solution for the problem that #32778 was supposed to solve. In practice, it seems to break nt services on master. We should revert it for now until we have time to debug it in a later alpha series.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32960CID 1457825: stub version of nt_service_parse_options() makes coverity think ...2020-06-13T15:49:58ZNick MathewsonCID 1457825: stub version of nt_service_parse_options() makes coverity think we have dead code```
*** CID 1457825: Possible Control flow issues (DEADCODE)
/src/app/main/main.c: 1244 in tor_run_main()
1238 memcpy(argv + tor_cfg->argc, tor_cfg->argv_owned,
1239 tor_cfg->argc_owned*sizeof(char*));
1240 ...```
*** CID 1457825: Possible Control flow issues (DEADCODE)
/src/app/main/main.c: 1244 in tor_run_main()
1238 memcpy(argv + tor_cfg->argc, tor_cfg->argv_owned,
1239 tor_cfg->argc_owned*sizeof(char*));
1240
1241 int done = 0;
1242 result = nt_service_parse_options(argc, argv, &done);
1243 if (done)
>>> CID 1457825: Possible Control flow issues (DEADCODE)
>>> Execution cannot reach this statement: "goto done;".
1244 goto done;
1245
1246 pubsub_install();
1247
1248 {
1249 int init_rv = tor_init(argc, argv);
```Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32847Tor 0.4.3.0-alpha-dev asserts when quitting while visiting an onion service2020-06-13T15:49:37ZTracTor 0.4.3.0-alpha-dev asserts when quitting while visiting an onion serviceReproducibility: often
Steps:
Quit Tor Browser Nightly.
What happened:
Crash.
Expected result:
No crash.
**Trac**:
**Username**: rex4539Reproducibility: often
Steps:
Quit Tor Browser Nightly.
What happened:
Crash.
Expected result:
No crash.
**Trac**:
**Username**: rex4539Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32778Initialise pubsub in Windows NT service mode2020-06-13T15:49:15ZcypherpunksInitialise pubsub in Windows NT service modei don't know what this error is about. Seen in logs many thousands of many of this log lines (650k), even if they tell to not warn about it again.
```
Dec 17 01:17:40.000 [warn] {HANDSHAKE} 20190 connections have failed:
Dec 17 01:17:40....i don't know what this error is about. Seen in logs many thousands of many of this log lines (650k), even if they tell to not warn about it again.
```
Dec 17 01:17:40.000 [warn] {HANDSHAKE} 20190 connections have failed:
Dec 17 01:17:40.000 [warn] {HANDSHAKE} 20190 connections died in state connect()ing with SSL state (No SSL object)
Dec 17 01:17:40.000 [warn] {BUG} tor_bug_occurred_(): Bug: pubsub_publish.c:37: pubsub_pub_: Non-fatal assertion !(! d) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.5 )
Dec 17 01:17:40.000 [warn] {BUG} Bug: Tor 0.4.2.5: Non-fatal assertion !(! d) failed in pubsub_pub_ at pubsub_publish.c:37. (Stack trace not available) (on Tor 0.4.2.5 )
Dec 17 01:17:40.000 [warn] {BUG} tor_bug_occurred_(): Bug: pubsub_publish.c:37: pubsub_pub_: Non-fatal assertion !(! d) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.5 )
Dec 17 01:17:40.000 [warn] {BUG} Bug: Tor 0.4.2.5: Non-fatal assertion !(! d) failed in pubsub_pub_ at pubsub_publish.c:37. (Stack trace not available) (on Tor 0.4.2.5 )
Dec 17 01:17:40.000 [warn] {CONTROL} Problem bootstrapping. Stuck at 0% (starting): Starting. (Connection timed out [WSAETIMEDOUT ]; TIMEOUT; count 20192; recommendation warn; host CE3FE883C6C9EF475EA097DC3E33A6F32B852DA1 at 78.129.218.56:443)
```Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32663Require coccinelle 1.0.4 in check_cocci_parse.sh2020-06-13T15:48:48ZteorRequire coccinelle 1.0.4 in check_cocci_parse.shIn #31919, we upgraded most of our CI jobs to Ubuntu bionic, so that we had a recent enough version of coccinelle (1.0.4 or later).
But we didn't put a minimum coccinelle version requirement in check_cocci_parse.sh.
We should also chec...In #31919, we upgraded most of our CI jobs to Ubuntu bionic, so that we had a recent enough version of coccinelle (1.0.4 or later).
But we didn't put a minimum coccinelle version requirement in check_cocci_parse.sh.
We should also check what happens if we install coccinelle on Windows.
For details, see:
https://trac.torproject.org/projects/tor/ticket/32500#comment:18Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32594Fix CID 1455953: Resource leaks in #324272020-06-13T15:48:31ZteorFix CID 1455953: Resource leaks in #32427```
** CID 1455953: Resource leaks (RESOURCE_LEAK)
/src/app/config/config.c: 1983 in options_act_reversible()
________________________________________________________________________________________________________
*** CID 1455953: ...```
** CID 1455953: Resource leaks (RESOURCE_LEAK)
/src/app/config/config.c: 1983 in options_act_reversible()
________________________________________________________________________________________________________
*** CID 1455953: Resource leaks (RESOURCE_LEAK)
/src/app/config/config.c: 1983 in options_act_reversible()
1977 tor_assert(*msg);
1978
1979 options_rollback_log_transaction(log_transaction);
1980 options_rollback_listener_transaction(listener_transaction);
1981
1982 done:
CID 1455953: Resource leaks (RESOURCE_LEAK)
Variable "listener_transaction" going out of scope leaks the storage it points to.
1983 return r;
1984 }
1985
1986 /** If we need to have a GEOIP ip-to-country map to run with our configured
1987 * options, return 1 and set *<b>reason_out</b> to a description of why. */
1988 int
```Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32472buf_flush_to_tls: Non-fatal assertion !(flushlen > *buf_flushlen)2020-06-13T15:50:31ZDavid Gouletdgoulet@torproject.orgbuf_flush_to_tls: Non-fatal assertion !(flushlen > *buf_flushlen)Had this on my relay because I ran out of disk space due to `debug.log` being on.
```
Nov 05 12:39:01.801 [warn] tor_bug_occurred_(): Bug: src/lib/tls/buffers_tls.c:152: buf_flush_to_tls: Non-fatal assertion !(flushlen > *buf_flushlen) ...Had this on my relay because I ran out of disk space due to `debug.log` being on.
```
Nov 05 12:39:01.801 [warn] tor_bug_occurred_(): Bug: src/lib/tls/buffers_tls.c:152: buf_flush_to_tls: Non-fatal assertion !(flushlen > *buf_flushlen) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.3.0-alpha-dev 4413b98190d94b54)
```
So the code that exploded is:
```
if (BUG(flushlen > *buf_flushlen)) {
flushlen = *buf_flushlen;
}
```
It was triggered by lack of disk space for sure.
The only thing I can see is if `connection_handle_write_impl()` was called with `force = 1` which happens with `connection_flush()` which makes tor use the bucket limit instead of the outbuf "flushlen" and thus could lead to that assert().Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/31669Invalid signature for service descriptor signing key: expired2020-06-13T15:45:22ZTracInvalid signature for service descriptor signing key: expiredwhen searching for this log entry: #26932
The following log entry has been seen on exit relays running in OfflineMasterKey mode. Online keys did not expire, relay did not shutdown when this log entry was observed. We did not observe any...when searching for this log entry: #26932
The following log entry has been seen on exit relays running in OfflineMasterKey mode. Online keys did not expire, relay did not shutdown when this log entry was observed. We did not observe any service degradation.
```
Invalid signature for service descriptor signing key: expired
```
**Trac**:
**Username**: a_pTor: 0.4.3.x-finalGeorge KadianakisGeorge Kadianakis