| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
ticket30454_035_01
|
|
Unify this with the trunnel ABI so we don't duplicate.
Part of #30454
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
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>
|
|
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>
|
|
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>
|
|
Remove the hs_intro_ack_status_t enum and move the value into trunnel. Only
use these values from now on in the intro point code.
Interestingly enough, the client side also re-define these values in hs_cell.h
with the hs_cell_introd_ack_status_t enum. Next commit will fix that and force
to use the trunnel ABI.
Part of #30454
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Closes ticket 30452.
|
|
Fortunately, in 0.3.5.1-alpha we improved logging for various
failure cases involved with onion service client auth.
Unfortunately, for this one, we freed the file right before logging
its name.
Fortunately, tor_free() sets its pointer to NULL, so we didn't have
a use-after-free bug.
Unfortunately, passing NULL to %s is not defined.
Fortunately, GCC 9.1.1 caught the issue!
Unfortunately, nobody has actually tried building Tor with GCC 9.1.1
before. Or if they had, they didn't report the warning.
Fixes bug 30475; bugfix on 0.3.5.1-alpha.
|
|
The INTRODUCE1 trunnel definition file doesn't support that value so it can
not be used else it leads to an assert on the intro point side if ever tried.
Fortunately, it was impossible to reach that code path.
Part of #30454
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
|
|
Fixes conflicts and also moves bandwidth-file-digest.
|
|
Fixes bug 30316; bugfix on 0.3.5.1-alpha.
|
|
|
|
In this patch we lower the log level of the failures for the three calls
to unlink() in networkstatus_set_current_consensus(). These errors might
trigger on Windows because the memory mapped consensus file keeps the
file in open state even after we have close()'d it. Windows will then
error on the unlink() call with a "Permission denied" error.
The consequences of ignoring these errors is that we leave an unused
file around on the file-system, which is an easier way to fix this
problem right now than refactoring networkstatus_set_current_consensus().
See: https://bugs.torproject.org/29930
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We need to encode here instead of doing escaped(), since fwict
escaped() does not currently handle NUL bytes.
Also, use warn_if_nul_found in more cases to avoid duplication.
|
|
Use TOR_PRIuSZ in place of %zu.
|
|
Previously, our use of abort() would break anywhere that we didn't
include stdlib.h. This was especially troublesome in case where
tor_assert_nonfatal() was used with ALL_BUGS_ARE_FATAL, since that
one seldom gets tested.
As an alternative, we could have just made this header include
stdlib.h. But that seems bloaty.
Fixes bug 30189; bugfix on 0.3.4.1-alpha.
|
|
|
|
|
|
Trivial merge: a blank line was removed between 0.3.4 and 0.3.5.
|
|
|
|
|
|
|
|
|
|
The function compat_getdelim_ is used for tor_getline if tor is compiled
on a system that lacks getline and getdelim. These systems should be
very rare, considering that getdelim is POSIX.
If this system is further a 32 bit architecture, it is possible to
trigger a double free with huge files.
If bufsiz has been already increased to 2 GB, the next chunk would
be 4 GB in size, which wraps around to 0 due to 32 bit limitations.
A realloc(*buf, 0) could be imagined as "free(*buf); return malloc(0);"
which therefore could return NULL. The code in question considers
that an error, but will keep the value of *buf pointing to already
freed memory.
The caller of tor_getline() would free the pointer again, therefore
leading to a double free.
This code can only be triggered in dirserv_read_measured_bandwidths
with a huge measured bandwith list file on a system that actually
allows to reach 2 GB of space through realloc.
It is not possible to trigger this on Linux with glibc or other major
*BSD systems even on unit tests, because these systems cannot reach
so much memory due to memory fragmentation.
This patch is effectively based on the penetration test report of
cure53 for curl available at https://cure53.de/pentest-report_curl.pdf
and explained under section "CRL-01-007 Double-free in aprintf() via
unsafe size_t multiplication (Medium)".
|
|
Part of 29702.
|
