The client auth protocol allows attacker-controlled x25519 private keys being
passed around, which allows an attacker to potentially trigger the all-zeroes
assert for client_auth_sk in hs_descriptor.c:decrypt_descriptor_cookie().
We fixed that by making sure that an all-zeroes client auth key will not be
used.
There are no guidelines for validating x25519 private keys, and the assert was
there as a sanity check for code flow issues (we don't want to enter that
function with an unitialized key if client auth is being used). To avoid such
crashes in the future, we also changed the assert to a BUG-and-err.
Previously we just ignored this option, which would leave it unset,
and cause an assertion failure later on when running with the User
option.
Fixes bug 33668; bugfix on 0.4.3.1-alpha.
Copy required DLLs to test and app, before running tor's tests.
This ensures that tor.exe and test*.exe use the correct version of each
DLL. This fix is not required, but we hope it will avoid DLL search
issues in future.
Closes bug 33673; bugfix on 0.3.4.2-alpha.
For example, "TOR_SKIP_TESTCASES=crypto/.. ./src/test/test" will run
the tests and suppress all the "crypto/" tests. You could get the
same effect by running "./src/test/test :crypto/..", but that can be
harder to arrange from CI.
Part of a fix/workaround for 33643.
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.
In the openssl that I have, it should be safe to only check the size
of n. But if I'm wrong, or if other openssls work differently, we
should check whether any of the fields are too large.
Issue spotted by Teor.
