Commit Graph

32784 Commits

Author SHA1 Message Date
David Goulet
3789f22bcb hs: Implement a helper to repurpose a circuit
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>
2019-05-29 09:40:13 -04:00
Nick Mathewson
0e0cf4abd8 Tweak comments in tor_vasprintf(), and add a changes file for 30651 2019-05-29 09:38:57 -04:00
Tobias Stoeckmann
0d5a0b4f0c Fixed tor_vasprintf on systems without vasprintf.
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]
2019-05-29 09:33:24 -04:00
Nick Mathewson
bdf685e476 Changes file for bug 30614 2019-05-29 09:05:26 -04:00
Taylor R Campbell
7971b3a5a6 Use MAP_INHERIT_ZERO or MAP_INHERIT_NONE if available.
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 29955f13e5)
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 29955f13e5)
[Lost connection!]
2019-05-29 08:56:01 -04:00
Nick Mathewson
24a2352d56 Trivial fix for a trivial warning with gcc 9.1.1
Fix on 4e3d144fb0940d8ee5a89427d471ea3656e8e122; bug not in any
released Tor.
2019-05-28 19:45:50 -04:00
David Goulet
ff9aa32143 Merge branch 'tor-github/pr/1047' 2019-05-28 14:59:07 -04:00
teor
9eb221b2d2
Travis: make stem log a controller trace, and tail stem's tor log
In Travis, make stem log a controller trace to the console.
And tail stem's tor log after failure.

Closes ticket 30591.
2019-05-28 10:20:36 +10:00
George Kadianakis
0a86f14add Merge branch 'tor-github/pr/1042' 2019-05-27 14:22:01 +03:00
George Kadianakis
130eb227ac Merge branch 'tor-github/pr/1043' 2019-05-27 14:20:51 +03:00
Nick Mathewson
fcd51fd49f Tests for deciding how full our relay cells should be 2019-05-27 14:20:36 +03:00
Nick Mathewson
0bc1241494 Make sure that we send at least some random data in RELAY_DATA cells
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.
2019-05-27 14:20:07 +03:00
Roger Dingledine
94914e2a4d trivial whitespace fixes 2019-05-26 17:32:42 -04:00
Nick Mathewson
6d9e47702f changes file for test coverage 2019-05-24 07:42:59 -04:00
Nick Mathewson
7893f2cd73 cov-test-determinism: use the same RNG seed as in travis.yml
We added this facility so that we could get deterministic PRNG
behavior for coverage testing on tests that use a replaced PRNG.
We need to have our coverage determinism tool test for this as well.
2019-05-23 14:36:01 -04:00
Nick Mathewson
07ccffa989 Coverage: do not include test-rebind in coverage builds.
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.)
2019-05-23 12:48:51 -04:00
Nick Mathewson
b882810245 In coverage builds, use branch-free timeradd() and timersub()
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.
2019-05-23 12:48:51 -04:00
Nick Mathewson
2bb5d8148b In coverage builds, avoid basic-block complexity in log_debug
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.
2019-05-23 12:48:51 -04:00
David Goulet
29955f13e5 Merge branch 'tor-github/pr/1022' 2019-05-23 09:50:28 -04:00
David Goulet
e13e2012b9 Merge branch 'tor-github/pr/1034' 2019-05-23 09:40:07 -04:00
David Goulet
327bb0e2ca Merge branch 'tor-github/pr/988' 2019-05-23 09:30:36 -04:00
Nick Mathewson
530d1179ff Extract length-deciding function from package_raw_inbuf. 2019-05-23 08:28:46 -04:00
Roger Dingledine
e4d1187584 refactor logic to decide how much to package from inbuf
no actual changes in behavior
2019-05-23 08:28:46 -04:00
Nick Mathewson
57ee0e3af9 Only reject POSTDESCRIPTOR purpose= when the purpose is unrecognized
Fixes bug 30580; bugfix on 0.4.1.1-alpha.
2019-05-23 08:24:29 -04:00
Nick Mathewson
ebe39dcb92 Now this repository is full of 0.4.1.1-alpha-dev 2019-05-22 18:07:29 -04:00
Nick Mathewson
fa410162a3 circuitpadding tests: Use tt_i64_op() to compare int64_t values
Bug not in any released Tor.
2019-05-22 15:19:24 -04:00
Nick Mathewson
c93ea09d29 More 0.4.1.1-alpha hangelogs edits
(credit to seborn here)
2019-05-22 13:57:34 -04:00
Nick Mathewson
fa57b6cfb0 Fold last entry into changelog 2019-05-22 12:00:20 -04:00
Nick Mathewson
3a7ed8bc5f Bump to 0.4.1.1-alpha 2019-05-22 11:56:02 -04:00
Nick Mathewson
24c2502070 Merge remote-tracking branch 'dgoulet/ticket30454_035_01' 2019-05-22 11:50:46 -04:00
Nick Mathewson
e6b862e6a8 Merge branch 'ticket30428_041_02_squashed' 2019-05-22 11:48:43 -04:00
David Goulet
0cad83bea4 sendme: Add non fatal asserts for extra safety
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>
2019-05-22 11:47:20 -04:00
David Goulet
5479ffabf8 sendme: Always pop last SENDME digest from circuit
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>
2019-05-22 11:47:20 -04:00
David Goulet
482c4972b9 sendme: Clarify how sendme_circuit_cell_is_next() works
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>
2019-05-22 11:47:20 -04:00
David Goulet
3835a3acf5 sendme: Properly record SENDMEs on both edges
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>
2019-05-22 11:47:20 -04:00
David Goulet
44265dd671 sendme: Never fallback to v0 if unknown version
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>
2019-05-22 11:47:20 -04:00
David Goulet
69e0d5bfc7 sendme: Validate v1 SENDMEs on both client and exit side
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>
2019-05-22 11:47:20 -04:00
David Goulet
59b9eecc19 sendme: Record cell digest on both client and exit
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>
2019-05-22 11:47:20 -04:00
David Goulet
245dccb77d Merge remote-tracking branch 'nickm/ticket30454_034_01_squashed' into ticket30454_035_01 2019-05-22 11:43:55 -04:00
Nick Mathewson
21b051d1cb Edit changelog entries for clarity and conciseness 2019-05-22 11:06:37 -04:00
Nick Mathewson
5614137a92 light movement and editing on changelog 2019-05-21 19:18:58 -04:00
Nick Mathewson
e2d3d44496 Add a new "autostyle" make target to run all of our reformatting
Closes ticket 30539.
2019-05-20 12:08:30 -04:00
Nick Mathewson
66eb0a5a32 updateCopyright: look at the current year. 2019-05-20 12:02:20 -04:00
Nick Mathewson
2f31c8146f rectify_include_paths: warn instead of aborting on duplicate headers
We have two sendme.h files at the moment; we should fix that, but
not in this branch.
2019-05-20 11:52:45 -04:00
rl1987
2845607f97 In microdesc_cache_reload(), set journal length to length of string we read
Hopefully this will fix CID 1444769.
2019-05-20 09:08:10 -04:00
David Goulet
56908c6f1c hs: Remove hs_cell_onion_key_type_t enum
Unify this with the trunnel ABI so we don't duplicate.

Part of #30454

Signed-off-by: David Goulet <dgoulet@torproject.org>
2019-05-20 08:56:34 -04:00
David Goulet
7d3e904a27 trunnel: Remove INTRODUCE1 status code IN statement
We want to support parsing a cell with unknown status code so we are forward
compatible.

Part of #30454

Signed-off-by: David Goulet <dgoulet@torproject.org>
2019-05-20 08:56:34 -04:00
David Goulet
9f52b87518 hs: Add changes file for #30454
Signed-off-by: David Goulet <dgoulet@torproject.org>
2019-05-20 08:56:34 -04:00
David Goulet
79cfe2ddd7 hs: Remove hs_intro_auth_key_type_t enum
Like the previous commit about the INTRODUCE_ACK status code, change all auth
key type to use the one defined in the trunnel file.

Standardize the use of these auth type to a common ABI.

Part of #30454

Signed-off-by: David Goulet <dgoulet@torproject.org>
2019-05-20 08:56:34 -04:00
David Goulet
dcc1d8d15b hs: Get rid of duplicate hs_cell_introd_ack_status_t
This enum was the exact same as hs_intro_ack_status_t that was removed at the
previous commit. It was used client side when parsing the INTRODUCE_ACK cell.

Now, the entire code dealing with the INTRODUCE_ACK cell (both sending and
receiving) have been modified to all use the same ABI defined in the trunnel
introduce1 file.

Finally, the client will default to the normal behavior when receiving an
unknown NACK status code which is to note down that we've failed and re-extend
to the next intro point. This way, unknown status code won't trigger a
different behavior client side.

Part of #30454.

Signed-off-by: David Goulet <dgoulet@torproject.org>
2019-05-20 08:56:34 -04:00