Fixes bug 40078.
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.
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.
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.
The "engines.h" header has lots of stuff; the "opensslv.h" header
has the version number, which is all we actually need here.
We need to do this because we're about to change this header to
conditionally define OPENSSL_SUPPRESS_DEPRECATED, and it would be
too late to do so if we'd already included "engines.h".
We found this in #40076, after we started using buf_move_all() in
more places. Fixes bug #40076; bugfix on 0.3.3.1-alpha. As far as
I know, the crash only affects master, but I think this warrants a
backport, "just in case".
This patch ensures that we strip "\r" characters on both Windows as well
as Unix when we read text files. This should prevent the issue where
some Tor state files have been moved from a Windows machine, and thus
contains CRLF line ending, to a Unix machine where only \n is needed.
We add a test-case to ensure that we handle this properly on all our
platforms.
See: https://bugs.torproject.org/tpo/core/tor/33781
This patch changes our bits-to-bytes conversion logic in the NSS
implementation of `tor_tls_cert_matches_key()` from using (x >> 3) to
((x + 7) >> 3) since DER bit-strings are allowed to contain a number of
bits that is not a multiple of 8.
Additionally, we add a comment on why we cannot use the
`DER_ConvertBitString()` macro from NSS, as we would potentially apply
the bits-to-bytes conversion logic twice, which would lead to an
insignificant amount of bytes being compared in
`SECITEM_ItemsAreEqual()` and thus turn the logic into being a
prefix match instead of a full match.
The `DER_ConvertBitString()` macro is defined in NSS as:
/*
** Macro to convert der decoded bit string into a decoded octet
** string. All it needs to do is fiddle with the length code.
*/
#define DER_ConvertBitString(item) \
{ \
(item)->len = ((item)->len + 7) >> 3; \
}
Thanks to Taylor Yu for spotting this problem.
This patch is part of the fix for TROVE-2020-001.
See: https://bugs.torproject.org/33119
We add constness to `peer_info_orig_len` and `cert_info_orig_len` in
`tor_tls_cert_matches_key` to ensure that we don't accidentally alter
the variables.
This patch is part of the fix for TROVE-2020-001.
See: https://bugs.torproject.org/33119
This patch fixes an out-of-bound memory read in
`tor_tls_cert_matches_key()` when Tor is compiled to use Mozilla's NSS
instead of OpenSSL.
The NSS library stores some length fields in bits instead of bytes, but
the comparison function found in `SECITEM_ItemsAreEqual()` needs the
length to be encoded in bytes. This means that for a 140-byte,
DER-encoded, SubjectPublicKeyInfo struct (with a 1024-bit RSA public key
in it), we would ask `SECITEM_ItemsAreEqual()` to compare the first 1120
bytes instead of 140 (140bytes * 8bits = 1120bits).
This patch fixes the issue by converting from bits to bytes before
calling `SECITEM_ItemsAreEqual()` and convert the `len`-fields back to
bits before we leave the function.
This patch is part of the fix for TROVE-2020-001.
See: https://bugs.torproject.org/33119
GCC added an implicit-fallthrough warning a while back, where it
would complain if you had a nontrivial "case:" block that didn't end
with break, return, or something like that. Clang recently added
the same thing.
GCC, however, would let you annotate a fall-through as intended by
any of various magic "/* fall through */" comments. Clang, however,
only seems to like "__attribute__((fallthrough))". Fortunately, GCC
accepts that too.
A previous commit in this branch defined a FALLTHROUGH macro to do
the right thing if GNUC is defined; here we replace all of our "fall
through" comments with uses of that macro.
This is an automated commit, made with the following perl one-liner:
#!/usr/bin/perl -i -p
s#/\* *falls? ?thr.*?\*/#FALLTHROUGH;#i;
This macro defers to __attribute__((fallthrough)) on GCC (and
clang). Previously we had been using GCC's magic /* fallthrough */
comments, but clang very sensibly doesn't accept those.
Since not all compiler recognize it, we only define it when our
configure script detects that it works.
Part of a fix for 34078.
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.
Although OpenSSL before 1.1.1 is no longer supported, it's possible
that somebody is still using it with 0.3.5, so we probably shouldn't
break it with this fix.
We introduced these BUG() checks in b0ddaac074 to prevent a
recurrence of bug 23690. But there's a report of the BUG() message
getting triggered and filling up the disk. Let's change it to
IF_BUG_ONCE().
Fixes bug 33093; bugfix on 0.3.2.2-alpha.
Doing so caused us to crash in some unusual circumstances, such as
using --verify-config to verify a configuration that failed during
the options_act() stage.
Fixes bug 32407; bugfix on 0.3.3.1-alpha.
When processing a %included folder, a bug caused the pointer to
the last element of the options list to be set to NULL when
processing a file with only comments or whitepace. This could
cause options from other files on the same folder to be
discarded depending on the lines after the affected %include.