Leave the other rend and hs_ident data around until circuit free, since code
may still try to inspect it after marking the circuit for close. The
circuitmap is the important thing to clean up, since repurposed
intropoints must be removed from this map to ensure validity.

This reverts commit 3789f22b.

This reverts commit 41b94722.

This can cause issues if the circuit was repurposed into a padding circuit
instead of closing, since in that case we will wipe off the rend_data.

This happened when I went to fix long lines after running "make
autostyle".

If "Log debug ..." is not set, the decrement never happens. This lead to the
package/deliver window to be out of sync at the stream level and thus breaking
the connection after 50+ cells.

Fixes #30628

Signed-off-by: David Goulet <dgoulet@torproject.org>

When this function was implemented, it counted all the entry guards
in the bridge set.  But this included previously configured bridges,
as well as currently configured ones!  Instead, only count the
_filtered_ bridges (ones that are configured and possibly reachable)
as maybe usable.

Fixes bug 29875; bugfix on 0.3.0.1-alpha.

Otherwise, we won't realize that we haven't got enough bridge
information to build circuits.  Part of a fix for ticket 29875.

For now, only tests HS circuit repurpose function.

Part of #29034

Signed-off-by: David Goulet <dgoulet@torproject.org>

This is necessary since shutting down libevent frees some pointer
that the subsystems want to free themselves. A longer term solution
will be to turn the evloop module into a subsystem itself, but for
now it is best to do the minimal fix.

Fixes bug 30629; bugfix on 0.4.1.1-alpha.

Previously, we were looking at our global settings to see what kind
of proxy we had.  But doing this would sometimes give us the wrong
results when we had ClientTransportPlugin configured but we weren't
using it for a particular connection.  In several places in the
code, we had added checks to see if we were _really_ using a PT or
whether we were using a socks proxy, but we had forgotten to do so
in at least once case.  Instead, since every time we call this
function we are asking about a single connection, it is probably
best just to make this function connection-specific.

Fixes bug 29670; bugfix on 0.2.6.2-alpha.

This looks a copy-and-paste error to me.  Fixes bug 30646; bugfix on
0.4.1.1-alpha.

When we repurpose a hidden service circuit, we need to clean up from the HS
circuit map and any HS related data structured contained in the circuit.

This commit adds an helper function that does it when repurposing a hidden
service circuit.

Fixes #29034

Signed-off-by: David Goulet <dgoulet@torproject.org>

Tobias Stoeckmann authored 5 years ago and Nick Mathewson committed 5 years ago

If tor is compiled on a system with neither vasprintf nor _vscprintf,
the fallback implementation exposes a logic flaw which prevents
proper usage of strings longer than 127 characters:

* tor_vsnprintf returns -1 if supplied buffer is not large enough,
  but tor_vasprintf uses this function to retrieve required length
* the result of tor_vsnprintf is not properly checked for negative
  return values

Both aspects together could in theory lead to exposure of uninitialized
stack memory in the resulting string. This requires an invalid format
string or data that exceeds integer limitations.

Fortunately tor is not even able to run with this implementation because
it runs into asserts early on during startup. Also the unit tests fail
during a "make check" run.

Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>

  [backported to 0.2.9 by nickm]

Taylor R Campbell authored 5 years ago and Nick Mathewson committed 5 years ago

Fixes assertion failure in tests on NetBSD:

slow/prob_distr/stochastic_log_logistic: [forking] May 25 03:56:58.091 [err] tor_assertion_failed_(): Bug: src/lib/crypt_ops/crypto_rand_fast.c:184: crypto_fast_rng_new_from_seed: Assertion inherit != INHERIT_RES_KEEP failed; aborting. (on Tor 0.4.1.1-alpha-dev 29955f13)
May 25 03:56:58.091 [err] Bug: Assertion inherit != INHERIT_RES_KEEP failed in crypto_fast_rng_new_from_seed at src/lib/crypt_ops/crypto_rand_fast.c:184: . (Stack trace not available) (on Tor 0.4.1.1-alpha-dev 29955f13)
[Lost connection!]

Fix on 4e3d144f; bug not in any
released Tor.

Proposal 289 prevents SENDME-flooding by requiring the other side to
authenticate the data it has received.  But this data won't actually
be random if they are downloading a known resource.  "No problem",
we said, "let's fell the empty parts of our cells with some
randomness!" and we did that in #26871.

Unfortunately, if the relay data payloads are all completely full,
there won't be any empty parts for us to randomize.

Therefore, we now pick random "randomness windows" between
CIRCWINDOW_INCREMENT/2 and CIRCWINDOW_INCREMENT. We remember whether we have
sent a cell containing at least 16 bytes of randomness in that window.  If we
haven't, then when the window is exhausted, we send one.  (This window approach
is designed to lower the number of rng checks we have to do.  The number 16 is
pulled out of a hat to change the attacker's guessing difficulty to
"impossible".)

Implements 28646.

Because it invokes the Tor mainloop, it does unpredictable things to
test coverage of a lot of code that it doesn't actually test at
all.  (It is more an integration test than anything else.)

The ordinary definitions of timeradd() and timersub() contain a
branch. However, in coverage builds, this means that we get spurious
complaints about partially covered basic blocks, in a way that makes
our coverage determinism harder to check.

Ordinarily we skip calling log_fn(LOG_DEBUG,...) if debug logging is
completely disabled.  However, in coverage builds, this means that
we get spurious complaints about partially covered basic blocks, in
a way that makes our coverage determinism harder to check.

Roger Dingledine authored 6 years ago and Nick Mathewson committed 5 years ago

no actual changes in behavior

Fixes bug 30580; bugfix on 0.4.1.1-alpha.

Bug not in any released Tor.

David Goulet authored 5 years ago and Nick Mathewson committed 5 years ago

Two non fatal asserts are added in this commit. First one is to see if the
SENDME digest list kept on the circuit for validation ever grows bigger than
the maximum number of expected SENDME on a circuit (currently 10).

The second one is to know if we ever send more than one SENDME at a time on a
circuit. In theory, we shouldn't but if we ever do, the v1 implementation
wouldn't work because we only keep one single cell digest (the previous cell
to the SENDME) on the circuit/cpath. Thus, sending two SENDME consecutively
will lead to a mismatch on the other side because the same cell digest would
be use and thus the circuit would collapse.

Finally, add an extra debug log in case we emit a v0 which also includes the
consensus emit version in that case.

Part of #30428

Signed-off-by: David Goulet <dgoulet@torproject.org>

David Goulet authored 5 years ago and Nick Mathewson committed 5 years ago

We must not accumulate digests on the circuit if the other end point is using
another SENDME version that is not using those digests like v0.

This commit makes it that we always pop the digest regardless of the version.

Part of #30428

Signed-off-by: David Goulet <dgoulet@torproject.org>

David Goulet authored 5 years ago and Nick Mathewson committed 5 years ago

Commit 4ef8470fa5480d3b was actually reverted before because in the end we
needed to do this minus 1 check on the window.

This commit clarifies that in the code, takes the useful comment changes from
4ef8470fa5480d3b and makes sendme_circuit_cell_is_next() private since it
behaves in a very specific way that one external caller might expect.

Part of #30428.

Signed-off-by: David Goulet <dgoulet@torproject.org>

David Goulet authored 5 years ago and Nick Mathewson committed 5 years ago

Turns out that we were only recording the "b_digest" but to have
bidirectionnal authenticated SENDMEs, we need to use the "f_digest" in the
forward cell situation.

Because of the cpath refactoring, this commit plays with the crypt_path_ and
relay_crypto_t API a little bit in order to respect the abstractions.

Previously, we would record the cell digest as the SENDME digest in the
decrypt cell function but to avoid code duplication (both directions needs to
record), we now do that right after iff the cell is recognized (at the edge).
It is now done in circuit_receive_relay_cell() instead.

We now also record the cell digest as the SENDME digest in both relay cell
encryption functions since they are split depending on the direction.
relay_encrypt_cell_outbound() and relay_encrypt_cell_inbound() need to
consider recording the cell digest depending on their direction (f vs b
digest).

Fixes #30428

Signed-off-by: David Goulet <dgoulet@torproject.org>

David Goulet authored 5 years ago and Nick Mathewson committed 5 years ago

There was a missing cell version check against our max supported version. In
other words, we do not fallback to v0 anymore in case we do know the SENDME
version.

We can either handle it or not, never fallback to the unauthenticated version
in order to avoid gaming the authenticated logic.

Add a unit tests making sure we properly test that and also test that we can
always handle the default emit and accepted versions.

Fixes #30428

Signed-off-by: David Goulet <dgoulet@torproject.org>

David Goulet authored 5 years ago and Nick Mathewson committed 5 years ago

The validation of the SENDME cell is now done as the very first thing when
receiving it for both client and exit. On failure to validate, the circuit is
closed as detailed in the specification.

Part of #30428

Signed-off-by: David Goulet <dgoulet@torproject.org>

David Goulet authored 5 years ago and Nick Mathewson committed 5 years ago

It turns out that only the exit side is validating the authenticated SENDME v1
logic and never the client side. Which means that if a client ever uploaded
data towards an exit, the authenticated SENDME logic wouldn't apply.

For this to work, we have to record the cell digest client side as well which
introduced a new function that supports both type of edges.

This also removes a test that is not valid anymore which was that we didn't
allow cell recording on an origin circuit (client).

Part of #30428

Signed-off-by: David Goulet <dgoulet@torproject.org>