Nick Mathewson [Fri, 5 Nov 2021 17:23:05 +0000 (13:23 -0400)]
Reverse the direction of the test for openssl 3.0.0
Previously the logic was reversed, and always gave the wrong answer.
This has no other effect than to change whether we suppress
deprecated API warnings.
David Goulet [Fri, 5 Nov 2021 14:10:24 +0000 (10:10 -0400)]
protover: Move all hardcoded lists in one place
This also moves the warnings and add some theatrical effect around the
code so anyone modifying those list should notice the warnings signs and
read the comment accordingly.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Alexander Færøy [Fri, 5 Feb 2021 17:12:52 +0000 (17:12 +0000)]
Fix Windows build.
While trying to resolve our CI issues, the Windows build broke with an
unused function error:
src/test/test_switch_id.c:37:1: error: ‘unprivileged_port_range_start’
defined but not used [-Werror=unused-function]
We solve this by moving the `#if !defined(_WIN32)` test above the
`unprivileged_port_range_start()` function defintion such that it is
included in its body.
Alexander Færøy [Thu, 4 Feb 2021 23:11:11 +0000 (23:11 +0000)]
Only check for bindable ports if we are unsure if it will fail.
We currently assume that the only way for Tor to listen on ports in the
privileged port range (1 to 1023), on Linux, is if we are granted the
NET_BIND_SERVICE capability. Today on Linux, it's possible to specify
the beginning of the unprivileged port range using a sysctl
configuration option. Docker (and thus the CI service Tor uses) recently
changed this sysctl value to 0, which causes our tests to fail as they
assume that we should NOT be able to bind to a privileged port *without*
the NET_BIND_SERVICE capability.
In this patch, we read the value of the sysctl value via the /proc/sys/
filesystem iff it's present, otherwise we assume the default
unprivileged port range begins at port 1024.
As reported by hdevalence our batch verification logic can cause an assert
crash.
The assert happens because when the batch verification of ed25519-donna fails,
the code in `ed25519_checksig_batch()` falls back to doing a single
verification for each signature.
The crash occurs because batch verification failed, but then all signatures
individually verified just fine.
That's because batch verification and single verification use a different
equation which means that there are sigs that can pass single verification
but fail batch verification.
Fixing this would require modding ed25519-donna which is not in scope for
this ticket, and will be soon deprecated in favor of arti and ed25519-dalek, so my branch instead removes batch verification.
David Goulet [Thu, 3 Jun 2021 13:33:21 +0000 (09:33 -0400)]
TROVE-2021-003: Check layer_hint before half-closed end and resolve cells
This issue was reported by Jann Horn part of Google's Project Zero.
Jann's one-sentence summary: entry/middle relays can spoof RELAY_END cells on
half-closed streams, which can lead to stream confusion between OP and
exit.
Nick Mathewson [Mon, 17 May 2021 12:50:01 +0000 (08:50 -0400)]
Assert on _all_ failures from RAND_bytes().
Previously, we would detect errors from a missing RNG
implementation, but not failures from the RNG code itself.
Fortunately, it appears those failures do not happen in practice
when Tor is using OpenSSL's default RNG implementation. Fixes bug
40390; bugfix on 0.2.8.1-alpha. This issue is also tracked as
TROVE-2021-004. Reported by Jann Horn at Google's Project Zero.
Nick Mathewson [Fri, 16 Apr 2021 21:26:59 +0000 (17:26 -0400)]
Stop calling evdns_set_random_bytes_fn()
This function has been a no-op since Libevent 2.0.4-alpha, when
libevent got an arc4random() implementation. Libevent has finally
removed it, which will break our compilation unless we stop calling
it. (This is currently breaking compilation in OSS-fuzz.)
Nick Mathewson [Wed, 3 Mar 2021 20:14:31 +0000 (15:14 -0500)]
Fix detection of point to insert signatures on a pending consensus.
We were looking for the first instance of "directory-signature "
when instead the correct behavior is to look for the first instance
of "directory-signature " at the start of a line.
Unfortunately, this can be exploited as to crash authorities while
they're voting.
Fixes #40316; bugfix on 0.2.2.4-alpha. This is TROVE-2021-002,
also tracked as CVE-2021-28090.
Nick Mathewson [Fri, 19 Feb 2021 17:31:19 +0000 (12:31 -0500)]
Disable the dump_desc() function.
It can be called with strings that should have been
length-delimited, but which in fact are not. This can cause a
CPU-DoS bug or, in a worse case, a crash.
Since this function isn't essential, the best solution for older
Tors is to just turn it off.
Fixes bug 40286; bugfix on 0.2.2.1-alpha when dump_desc() was
introduced.
David Goulet [Mon, 1 Feb 2021 17:45:32 +0000 (12:45 -0500)]
relay: Send back CONNECTION_REFUSED on reentry
The TORPROTOCOL reason causes the client to close the circuit which is not
what we want because other valid streams might be on it.
Instead, CONNECTION_REFUSED will leave it open but will not allow more streams
to be attached to it. The client then open a new circuit to the destination.
Closes #40270
Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet [Thu, 28 Jan 2021 02:49:56 +0000 (21:49 -0500)]
relay: Add bloomfiter of relay address + {OR|Dir}Port
In order to deny re-entry in the network, we now keep a bloomfilter of relay
ORPort + address and authorities ORPort + address and DirPort + address
combinations.
So when an Exit stream is handled, we deny anything connecting back into the
network on the ORPorts for relays and on the ORPort+DirPort for the
authorities.
Related to #2667
Signed-off-by: David Goulet <dgoulet@torproject.org>
Nick Mathewson [Wed, 13 Jan 2021 14:48:00 +0000 (09:48 -0500)]
Better fix for #40241 (--enable-all-bugs-are-fatal and fallthrough)
This one should work on GCC _and_ on Clang. The previous version
made Clang happier by not having unreachable "fallthrough"
statements, but made GCC sad because GCC didn't think that the
unconditional failures were really unconditional, and therefore
_wanted_ a FALLTHROUGH.
This patch adds a FALLTHROUGH_UNLESS_ALL_BUGS_ARE_FATAL macro that
seems to please both GCC and Clang in this case: ordinarily it is a
FALLTHROUGH, but when ALL_BUGS_ARE_FATAL is defined, it's an
abort().
Fixes bug 40241 again. Bugfix on earlier fix for 40241, which was
merged into maint-0.3.5 and forward, and released in 0.4.5.3-rc.
David Goulet [Mon, 11 Jan 2021 21:01:22 +0000 (16:01 -0500)]
hs-v3: Require reasonably live consensus
Some days before this commit, the network experienced a DDoS on the directory
authorities that prevented them to generate a consensus for more than 5 hours
straight.
That in turn entirely disabled onion service v3, client and service side, due
to the subsystem requiring a live consensus to function properly.
We know require a reasonably live consensus which means that the HSv3
subsystem will to its job for using the best consensus tor can find. If the
entire network is using an old consensus, than this should be alright.
If the service happens to use a live consensus while a client is not, it
should still work because the client will use the current SRV it sees which
might be the previous SRV for the service for which it still publish
descriptors for.
If the service is using an old one and somehow can't get a new one while
clients are on a new one, then reachability issues might arise. However, this
is a situation we already have at the moment since the service will simply not
work if it doesn't have a live consensus while a client has one.
Fixes #40237
Signed-off-by: David Goulet <dgoulet@torproject.org>
projects / thirdparty / tor.git / log
