Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:06:20Zhttps://gitlab.torproject.org/legacy/trac/-/issues/21470Write unit tests for security regressions2020-06-13T15:06:20ZteorWrite unit tests for security regressionsWhen we fix a security vulnerability like the ones in [
https://trac.torproject.org/projects/tor/wiki/TROVE TROVE], we sometimes forget to include a unit test.
Some security vulnerabilities are easy to test, such as parsing errors. We s...When we fix a security vulnerability like the ones in [
https://trac.torproject.org/projects/tor/wiki/TROVE TROVE], we sometimes forget to include a unit test.
Some security vulnerabilities are easy to test, such as parsing errors. We should write tests that fail with the bug, but succeed when it is fixed.
Here's an initial list of security fixes we can write unit tests for:
* #20894
* #21018
* #21278 (and #21450)
Let's open a child ticket of this ticket for each one.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21439Add a configure option to disable safety features that make fuzzing harder2020-06-13T15:06:14ZNick MathewsonAdd a configure option to disable safety features that make fuzzing harderWe've got quite a few places in our code where we use redundant safety features to prevent bugs from turning into really serious bugs. But many of those safety features interfere with fuzzing, by covering up any underlying bugs that fuz...We've got quite a few places in our code where we use redundant safety features to prevent bugs from turning into really serious bugs. But many of those safety features interfere with fuzzing, by covering up any underlying bugs that fuzzing would otherwise detect.
For example, I'm thinking of:
* The 4-byte sentinel word at the end of each buffer chunk
* Various places in our code where we NUL-terminate stuff that doesn't actually (we hope!) need to be NUL-terminated.
* The entire "memarea" fragmentation-resistant allocation strategy.
* Probably some other stuff too
But in addition to hardening our code a little, these features all make some classes of memory bug less likely to get noticed by the sanitizers.
Now, you might argue that there's no need to have a way to fuzz without those safety features, if they actually do provide safety. But on the other hand, they're meant to provide _redundant_ safety, and if they are ever actually needed, that's a bug in our code that we ought to fix.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21407Make the usecreatefast default 0 in tor to match the consensus2020-06-13T15:06:06ZteorMake the usecreatefast default 0 in tor to match the consensusIn #9386 we made clients use CREATE_FAST less, and changed the value in the consensus to 0. But we still use the default of 1 when bootstrapping (because there is no consensus).
We should change this default to 0.
Sticking this in 0.3....In #9386 we made clients use CREATE_FAST less, and changed the value in the consensus to 0. But we still use the default of 1 when bootstrapping (because there is no consensus).
We should change this default to 0.
Sticking this in 0.3.1 because it's a security hole for the reasons mentioned in #9386. (I'd go for 0.3.0, but that's frozen, and this change could introduce bootstrapping bugs.)Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21406The channel is_client flag is inaccurate2020-06-13T15:08:15ZteorThe channel is_client flag is inaccurateThe channel_t is_client flag is inaccurate: relays set it when the other end uses a CREATE_FAST cell, but usecreatefast is set to 0 in the consensus.
This means that the only time CREATE_FAST is used is when a relay gets an extend reque...The channel_t is_client flag is inaccurate: relays set it when the other end uses a CREATE_FAST cell, but usecreatefast is set to 0 in the consensus.
This means that the only time CREATE_FAST is used is when a relay gets an extend request *without* an ntor key, and the purpose of the circuit is *not* one of the hidden service purposes where TAP is allowed.
See should_use_create_fast_for_circuit() for details.Tor: 0.3.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/21334prop224: Update prop224 HS desriptor generation code to produce the latest de...2020-06-13T15:07:14ZGeorge Kadianakisprop224: Update prop224 HS desriptor generation code to produce the latest descriptor formatThis is the older cousin of #20852. In this ticket we need to go over our prop224 HS descriptor generation code and make it produce descriptors that conform with the latest format (which includes the fake client authorization entries and...This is the older cousin of #20852. In this ticket we need to go over our prop224 HS descriptor generation code and make it produce descriptors that conform with the latest format (which includes the fake client authorization entries and such).Tor: 0.3.1.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/21329onions/detached and onions/current should return empty lists instead of errors2017-05-15T19:44:31Zmeejahonions/detached and onions/current should return empty lists instead of errorsIf you do a GETINFO query on `onions/detached` or `onions/current` and there aren't any, a 551 error is returned. Most other things just return an empty list/value in this case and I think these should too.
One consequence of this is th...If you do a GETINFO query on `onions/detached` or `onions/current` and there aren't any, a 551 error is returned. Most other things just return an empty list/value in this case and I think these should too.
One consequence of this is that if you ask for `onions/current` with some other keys and there are no current onions, the whole query will fail.
So `GETINFO onions/current` should return `onions/current=` instead of an error.
For example you can try `carml cmd getinfo orconn-status onions/current` to see this behavior.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21293circuit_receive_relay_cell(): Bug: relay crypt failed. Dropping connection.2020-06-13T15:05:38Zs7rcircuit_receive_relay_cell(): Bug: relay crypt failed. Dropping connection.I've hit this today on a machine running Debian Jessie and Tor `0.3.0.1-alpha-dev (git-1a45398ffa713ca3+5156f73)` acting as an onion service client with a SocksPort open and used as well. Functionality appears not to be affected, everyth...I've hit this today on a machine running Debian Jessie and Tor `0.3.0.1-alpha-dev (git-1a45398ffa713ca3+5156f73)` acting as an onion service client with a SocksPort open and used as well. Functionality appears not to be affected, everything continues to run normally.
Besides the incoming rendezvous traffic, this instance also sends outgoing traffic via the SocksPort but to .onion destinations only, so it's mostly rendezvous traffic.
```
Jan 23 15:31:44.000 [warn] circuit_receive_relay_cell(): Bug: relay crypt failed. Dropping connection. (on Tor 0.3.0.1-alpha-dev )
```Tor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21211Write and analyze proposals for compressing consensus (diff)s with better alg...2020-06-13T15:05:24ZNick MathewsonWrite and analyze proposals for compressing consensus (diff)s with better algorithms**The idea:** Consensus documents are compressed with zlib, but nobody has to compress any given consensus more than once. Therefore, we can safely use more CPU compressing them, and save bandwidth on consensus downloads by switching to...**The idea:** Consensus documents are compressed with zlib, but nobody has to compress any given consensus more than once. Therefore, we can safely use more CPU compressing them, and save bandwidth on consensus downloads by switching to something else instead of zlib for consensuses.
This same analysis also applies to consensus diffs.
For this ticket, we should look at the code complexity and potential bandwidth savings here, and decide whether they are worth it.Tor: 0.3.1.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21210Analyze, and maybe improve, consensus diff proposal2020-06-13T15:05:24ZNick MathewsonAnalyze, and maybe improve, consensus diff proposalWe should use stats to re-run our numbers on the consensus diff proposal (140), and see how much bandwidth we expect to save. We should consider the impact of this proposal alongside alternative or related proposals, such as ones that w...We should use stats to re-run our numbers on the consensus diff proposal (140), and see how much bandwidth we expect to save. We should consider the impact of this proposal alongside alternative or related proposals, such as ones that would cause clients to download the consensus less frequently.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21155Similar to #14917: Client's choice of rend point can leak info about guard(s)...2020-06-13T15:05:16ZJaymSimilar to #14917: Client's choice of rend point can leak info about guard(s) of misconfigured hidden services with EntryNodes optionHello !
I discovered #14917 while configuring an onion service with the EntryNodes option set. I believe (after checking the tor-0.2.9.8 source code) that a similar problem arises when the EntryNodes option is set AND the operator confi...Hello !
I discovered #14917 while configuring an onion service with the EntryNodes option set. I believe (after checking the tor-0.2.9.8 source code) that a similar problem arises when the EntryNodes option is set AND the operator configures entry nodes that are part of the same family or the same /16. (let's say that the operator configures the service with 2 of its own guard nodes running in the same cloud provider, thinking this move is wise). Then this happens:
- When someone use a RDV point of the same family or the same /16 than the onion's guards, then as you said: "entry_list_is_constrained() is true, so populate_live_entry_guards() will happily return an empty list if your one choice is inappropriate, resulting in choose_random_entry_impl() returning NULL".
Is there a reason why we do not check family, /16 and user misconfiguration ? "EntryNodes fingerprint1, fingerprint1" works just fine for example. What do you think ?Tor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21151man page lists wrong default for DataDirectory2020-06-13T15:05:15ZRoger Dingledineman page lists wrong default for DataDirectoryIn my doc/tor.1 in my git checkout, I have
```
DataDirectory DIR
Store working data in DIR (Default: /usr/local/var/lib/tor)
```
Apparently the underlying code (in tor.1.txt) is
```
[[DataDirectory]] **DataDirectory** ...In my doc/tor.1 in my git checkout, I have
```
DataDirectory DIR
Store working data in DIR (Default: /usr/local/var/lib/tor)
```
Apparently the underlying code (in tor.1.txt) is
```
[[DataDirectory]] **DataDirectory** __DIR__::
Store working data in DIR (Default: @LOCALSTATEDIR@/lib/tor)
```
It looks like if DataDirectory remains unset (which is the default), on Windows you get
```
get_windows_conf_root()
```
whereas on other platforms, you get
```
d = "~/.tor";
```
and then it's only if you're running as root that you get
```
fn = tor_strdup(LOCALSTATEDIR PATH_SEPARATOR "tor");
```
But I admit that all of this is confusing, because we have functions like `find_torrc_filename()` and `get_default_conf_file()` and `get_torrc_fname()` so it's hard to say for sure.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21121Update fallback whitelist2020-06-13T16:06:00ZteorUpdate fallback whitelistRelay operators have emailed me with updates.
I'm tracking them in my github branch fallbacks-201701.Relay operators have emailed me with updates.
I'm tracking them in my github branch fallbacks-201701.Tor: 0.3.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/21120evdns_get_orig_address: tor_fragile_assert() warning for unknown rtype.2020-06-13T15:05:06ZTracevdns_get_orig_address: tor_fragile_assert() warning for unknown rtype.The trace (below) appeared while routinely examining my tor log while having network connectivity issues (arch is x86/32 bit, kernel is 3.11):
```
Jan 02 16:22:56.000 [warn] {BUG} tor_bug_occurred_(): Bug: src/or/dnsserv.c:294: evdns_ge...The trace (below) appeared while routinely examining my tor log while having network connectivity issues (arch is x86/32 bit, kernel is 3.11):
```
Jan 02 16:22:56.000 [warn] {BUG} tor_bug_occurred_(): Bug: src/or/dnsserv.c:294: evdns_get_orig_address: This line should not have been reached. (Future instances of this warning will be silenced.) (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
Jan 02 16:22:56.000 [warn] {BUG} Bug: Line unexpectedly reached at evdns_get_orig_address at src/or/dnsserv.c:294. Stack trace: (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
Jan 02 16:22:56.000 [warn] {BUG} Bug: /usr/bin/tor(log_backtrace+0x56) [0xb765aee6] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
Jan 02 16:22:56.000 [warn] {BUG} Bug: /usr/bin/tor(tor_bug_occurred_+0xf5) [0xb7676435] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
Jan 02 16:22:56.000 [warn] {BUG} Bug: /usr/bin/tor(dnsserv_resolved+0x255) [0xb7642435] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
Jan 02 16:22:56.000 [warn] {BUG} Bug: /usr/bin/tor(connection_ap_handshake_socks_resolved+0x8e) [0xb75fe4fe] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
Jan 02 16:22:56.000 [warn] {BUG} Bug: /usr/bin/tor(+0x593fe) [0xb75513fe] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
Jan 02 16:22:56.000 [warn] {BUG} Bug: /usr/bin/tor(+0x5d296) [0xb7555296] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
Jan 02 16:22:56.000 [warn] {BUG} Bug: /usr/bin/tor(circuit_receive_relay_cell+0x316) [0xb7556f66] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
Jan 02 16:22:56.000 [warn] {BUG} Bug: /usr/bin/tor(command_process_cell+0x22f) [0xb75d8f0f] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
Jan 02 16:22:56.000 [warn] {BUG} Bug: /usr/bin/tor(channel_queue_cell+0xd2) [0xb75b0882] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
Jan 02 16:22:56.000 [warn] {BUG} Bug: /usr/bin/tor(channel_tls_handle_cell+0x2bc) [0xb75b695c] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
Jan 02 16:22:56.000 [warn] {BUG} Bug: /usr/bin/tor(+0x11095b) [0xb760895b] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
Jan 02 16:22:56.000 [warn] {BUG} Bug: /usr/bin/tor(+0xf8df4) [0xb75f0df4] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
Jan 02 16:22:56.000 [warn] {BUG} Bug: /usr/bin/tor(connection_handle_read+0x7e3) [0xb75f9983] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
Jan 02 16:22:56.000 [warn] {BUG} Bug: /usr/bin/tor(+0x3458f) [0xb752c58f] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
Jan 02 16:22:56.000 [warn] {BUG} Bug: /usr/lib/libevent-2.1.so.6(+0x207d5) [0xb745a7d5] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
Jan 02 16:22:56.000 [warn] {BUG} Bug: /usr/lib/libevent-2.1.so.6(event_base_loop+0x2b4) [0xb745af84] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
Jan 02 16:22:56.000 [warn] {BUG} Bug: /usr/bin/tor(do_main_loop+0x46c) [0xb752732c] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
Jan 02 16:22:56.000 [warn] {BUG} Bug: /usr/bin/tor(tor_main+0x1315) [0xb7528965] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
Jan 02 16:22:56.000 [warn] {BUG} Bug: /usr/bin/tor(main+0x33) [0xb7523e23] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
Jan 02 16:22:56.000 [warn] {BUG} Bug: /lib/libc.so.6(__libc_start_main+0xe6) [0xb7033cc6] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
Jan 02 16:22:56.000 [warn] {BUG} Bug: /usr/bin/tor(+0x2bd11) [0xb7523d11] (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
```
**Trac**:
**Username**: mr-4Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21056Could not pick one of the responsible hidden service directories, because we ...2020-06-13T15:04:52ZTracCould not pick one of the responsible hidden service directories, because we requested them all recently without success.I am seeing connections to hidden services reliably fail, with this in the log:
Dec 21 13:50:16.000 [info] connection_ap_handshake_rewrite_and_attach(): Got a hidden service request for ID '[scrubbed]'
Dec 21 13:50:16.000 [info] connect...I am seeing connections to hidden services reliably fail, with this in the log:
Dec 21 13:50:16.000 [info] connection_ap_handshake_rewrite_and_attach(): Got a hidden service request for ID '[scrubbed]'
Dec 21 13:50:16.000 [info] connection_ap_handshake_rewrite_and_attach(): Unknown descriptor [scrubbed]. Fetching.
Dec 21 13:50:16.000 [debug] rend_client_refetch_v2_renddesc(): Fetching v2 rendezvous descriptor for service [scrubbed]
Dec 21 13:50:16.000 [info] pick_hsdir(): Could not pick one of the responsible hidden service directories, because we requested them all recently without success.
Dec 21 13:50:16.000 [info] pick_hsdir(): Could not pick one of the responsible hidden service directories, because we requested them all recently without success.
Dec 21 13:50:16.000 [info] fetch_v2_desc_by_addr(): Could not pick one of the responsible hidden service directories to fetch descriptors, because we already tried them all unsuccessfully.
In my test case, I have 2 hidden services running on a machine. Both have been started up for the first time in the past 5-10 minutes. On the same machine, I open concurrently two socks connections, one to each hidden service. Reiably, one of the socks connections succeeds, and the other fails. After it starts failing, retries using that onion address continue to fail for several minutes.
Kind of looks like one socks request is breaking the other one. This seems similar to #16501 and #15937 but I am pretty sure I am only making 2 socks connections, to two different onion addresses.
Attached log shows this occurring, and then after a while the bad state cleared and a retry to connect to the hidden service that it had not been able to resolve succeeded.
**Trac**:
**Username**: joeyhTor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21028tor never checks TLS certificate lifetimes2020-06-13T15:04:42Zteortor never checks TLS certificate lifetimesWe have tor_tls_check_lifetime(), why don't we use it?
This could be an issue if a relay never rotates its certificate, or its certificate is out of date because its clock is wrong.We have tor_tls_check_lifetime(), why don't we use it?
This could be an issue if a relay never rotates its certificate, or its certificate is out of date because its clock is wrong.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21008hs: Remove the introduction point private key material from hs_descriptor.h2020-06-13T15:04:36ZDavid Gouletdgoulet@torproject.orghs: Remove the introduction point private key material from hs_descriptor.hWe need to change the `curve25519_keypair_t` from `hs_desc_intro_point_t` to a public key only because both client and service will use that field.We need to change the `curve25519_keypair_t` from `hs_desc_intro_point_t` to a public key only because both client and service will use that field.Tor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/20988Test fgets_eagain fails on FreeBSD-amd642020-06-13T15:13:26ZcypherpunksTest fgets_eagain fails on FreeBSD-amd64According to the [BSD Buildbot](https://buildbot.pixelminers.net/builders)
```
util/fgets_eagain:
FAIL src/test/test_util.c:3952: assert(retptr OP_EQ buf): 0x0 vs 0x7fffffffe944
[fgets_eagain FAILED]
```
This means that fgets retur...According to the [BSD Buildbot](https://buildbot.pixelminers.net/builders)
```
util/fgets_eagain:
FAIL src/test/test_util.c:3952: assert(retptr OP_EQ buf): 0x0 vs 0x7fffffffe944
[fgets_eagain FAILED]
```
This means that fgets returns a null pointer on partial lines instead of the buffer as expected.
Previously this test was passing but started failing with [build #105](https://buildbot.pixelminers.net/builders/FreeBSD-amd64/builds/105). Looking at the changes to libc it looks like this is caused by [revision 305413](https://svnweb.freebsd.org/base/head/lib/libc/stdio/fgets.c?r1=305413&r2=305412&pathrev=305413) (which was added earlier in the same month the test started failing).
I'm unsure whether FreeBSD is right and other libc implementations are wrong or the other way around.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20913Increase fallback stability, flag percentage, and bandwidth2020-06-13T16:05:54ZteorIncrease fallback stability, flag percentage, and bandwidthIn #18828, I had to decrease the fallback criteria to get ~160 fallbacks.
It would be great to increase these to:
* Stability: 3 months+ (from 7 days)
* Flags: 95%+ (from 90%)
* Bandwidth: 2MBytes/s+ (from 1MByte/s)In #18828, I had to decrease the fallback criteria to get ~160 fallbacks.
It would be great to increase these to:
* Stability: 3 months+ (from 7 days)
* Flags: 95%+ (from 90%)
* Bandwidth: 2MBytes/s+ (from 1MByte/s)Tor: 0.3.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/20908Display the fingerprint when downloading consensuses from fallbacks2020-06-13T15:04:06ZteorDisplay the fingerprint when downloading consensuses from fallbacksJust using this for the bug number, will be fixed in #18828.Just using this for the bug number, will be fixed in #18828.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20571When we are really satisfied that it is right, tell protover.c about prop224 ...2020-06-13T15:02:57ZNick MathewsonWhen we are really satisfied that it is right, tell protover.c about prop224 HSDir supportThis will be trivial to do, but nontrivial to know when we should do it.
prop224-supporting hidden services and relays will need to know which Tor relays they should use to upload and download the new kind of descriptors. So, they shoul...This will be trivial to do, but nontrivial to know when we should do it.
prop224-supporting hidden services and relays will need to know which Tor relays they should use to upload and download the new kind of descriptors. So, they should use the preferred mechanism for it.
As of proposal 264, that's protocol subversions.
We should only advertise support for this server-side once we're pretty sure we aren't changing the server side any more.Tor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org