The tor_fragile_assert() bug has existed here since c8a5e2d588
in tor-0.2.1.7-alpha forever, but tor_fragile_assert() was mostly a
no-op until 0.2.9.1-alpha.
Fixes bug 19869.
When we refactored purpose_needs_anonymity(), we made it so _all_
bridge requests required anonymity. But that missed the case
that we are allowed to ask a bridge for its own descriptor.
With this patch, we consider the resource, and allow "authority.z"
("your own descriptor, compressed") for a bridge's server descriptor
to be non-anonymous.
Fix for bug 20410; bug not in any released Tor.
I believe that this should never trigger, but if it does, it
suggests that there was a gap between is_sensitive_dir_purpose and
purpose_needs_anonymity that we need to fill. Related to 20077.
This helps protect against bugs where any part of a buf_t's memory
is passed to a function that expects a NUL-terminated input.
It also closes TROVE-2016-10-001 (aka bug 20384).
This commit adds or improves the module-level documenation for:
buffers.c circuitstats.c command.c connection_edge.c control.c
cpuworker.c crypto_curve25519.c crypto_curve25519.h
crypto_ed25519.c crypto_format.c dircollate.c dirserv.c dns.c
dns_structs.h fp_pair.c geoip.c hibernate.c keypin.c ntmain.c
onion.c onion_fast.c onion_ntor.c onion_tap.c periodic.c
protover.c protover.h reasons.c rephist.c replaycache.c
routerlist.c routerparse.c routerset.c statefile.c status.c
tor_main.c workqueue.c
In particular, I've tried to explain (for each documented module)
what each module does, what's in it, what the big idea is, why it
belongs in Tor, and who calls it. In a few cases, I've added TODO
notes about refactoring opportunities.
I've also renamed an argument, and fixed a few DOCDOC comments.
(I've done this instead of changing the semantics of
router_compare_to_my_exit_policy, because dns.c uses
router_compare_to_my_exit_policy too, in a slightly weird way.)
Some compilers apparently noticed that p2len was allowed to be equal
to msg, and so maybe we would be doing memset(prompt2, ' ', 0), and
decided that we probably meant to do memset(prompt2, 0, 0x20);
instead.
Stupid compilers, doing optimization before this kind of warning!
My fix is to just fill the entire prompt2 buffer with spaces,
because it's harmless.
Bugfix on e59f0d4cb9, not in any released Tor.
(Specifically, carriage return after a quoted value in a config
line. Fixes bug 19167; bugfix on 0.2.0.16-alpha when we introduced
support for quoted values. Unit tests, changes file, and this
parenthetical by nickm.)
This is a kludge to deal with the fact that `tor_addr_t` doesn't contain
`sun_path`. This currently ONLY happens when circuit isolation is being
checked, for an isolation mode that is force disabled anyway, so the
kludge is "ugly but adequate", but realistically, making `tor_addr_t`
and the AF_UNIX SocksPort code do the right thing is probably the better
option.
Closes ticket 20303.
The LIBRESSL_VERSION_NUMBER check is needed because if our openssl
is really libressl, it will have an openssl version number we can't
really believe.
Previously, we would reject even rendezvous connections to IPv6
addresses when IPv6Exit was false. But that doesn't make sense; we
don't count that as "exit"ing. I've corrected the logic and tried
to make it a lottle more clear.
Fixes bug 18357; this code has been wrong since 9016d9e829 in
0.2.4.7-alpha.
When deleting unsuitable addresses in get_interface_address6_list(), to
avoid reordering IPv6 interface addresses and keep the order returned by
the OS, use SMARTLIST_DEL_CURRENT_KEEPORDER() instead of
SMARTLIST_DEL_CURRENT().
This issue was reported by René Mayrhofer.
[Closes ticket 20163; changes file written by teor. This paragraph
added by nickm]
We removed that feature in 0.2.4.2-alpha, but some comments seem to
have lingered.
I didn't add a changes/ file since this is just internal code cleanup.
(like clients do) rather than old-style router descriptors. Now bridges
will blend in with clients in terms of the circuits they build.
Fixes bug 6769; bugfix on 0.2.3.2-alpha.
Clients that use bridges were ignoring their cached microdesc-flavor
consensus files, because they only thought they should use the microdesc
flavor once they had a known-working bridge that could offer microdescs,
and at first boot no bridges are known-working.
This bug caused bridge-using clients to download a new microdesc consensus
on each startup.
Fixes bug 20269; bugfix on 0.2.3.12-alpha.
The client addr is essentially meaningless in this context (yes, it is
possible to explicitly `bind()` AF_LOCAL client side sockets to a path,
but no one does it, and there are better ways to grant that sort of
feature if people want it like using `SO_PASSCRED`).
As before, we check server protocols whenever server_mode(options)
is true and we check client protocols whenever server_mode(options)
is false.
Additionally, we now _also_ check client protocols whenever any
client port is set.
(Technically, we could just remove extend2 cell checking entirely,
since all Tor versions on our network are required to have it, but
let's keep this around as an example of How To Do It.)
(Despite the increased size of the consensus, this should have
approximately zero effect on the compressed consensus size, since
the "proto" line should be completely implied by the "v" line.)
[This is a brute-force method that potentially uses way too much
RAM. Need to rethink this a little. Right now you can DOS an
authority by saying "Foo=1-4294967295".]
Sierra provides clock_gettime(), but not pthread_condattr_setclock.
So we had better lot try to use CLOCK_MONOTONIC as our source for
time when waiting, since we ccan never actually tell the condition
that we mean CLOCK_MONOTONIC.
This isn't a tor bug yet, since we never actually pass a timeout to
tor_cond_wait() outside of the unit tests.
Not telling the cmux would sometimes cause an assertion failure in
relay.c when we tried to get an active circuit and found an "active"
circuit with no cells.
Additionally, replace that assert with a test and a log message.
Fix for bug 20203. This is actually probably a bugfix on
0.2.8.1-alpha, specifically my code in 8b4e5b7ee9 where I
made circuit_mark_for_close_() do less in order to simplify our call
graph. Thanks to "cypherpunks" for help diagnosing.
Our use of the (mockable) tor_close_socket() in the util/socket_..
tests confused coverity, which could no longer tell that we were
actually closing the sockets.
It's a macro that calls down to a function whose behavior has been
getting progresively more complicated.... but we named it as if it
were a variable. That's not so smart. So, replace it with a
function call to a function that was just doing "return
current_consensus".
Fixes bug 20176.
Commit 41cc1f612b introduced a "dns_request"
configuration value which wasn't set to 1 for an entry connection on the
DNSPort leading to a refusal to resolve the given hostname.
This commit set the dns_request flag by default for every entry connection
made to the DNSPort.
Fixes#20109
Signed-off-by: David Goulet <dgoulet@torproject.org>
For a brief moment in networkstatus_set_current_consensus(), the old
consensus has been freed, but the node_t objects still have dead
pointers to the routerstatus_t objects within it. During that
interval, we absolutely must not do anything that would cause Tor to
look at those dangling pointers.
Unfortunately, calling the (badly labeled!) current_consensus macro
or anything else that calls into we_use_microdescriptors_for_circuits(),
can make us look at the nodelist.
The fix is to make sure we identify the main consensus flavor
_outside_ the danger zone, and to make the danger zone much much
smaller.
Fixes bug 20103. This bug has been implicitly present for AGES; we
just got lucky for a very long time. It became a crash bug in
0.2.8.2-alpha when we merged 35bbf2e4a4 to make
find_dl_schedule start looking at the consensus, and 4460feaf28
which made node_get_all_orports less (accidentally) tolerant of
nodes with a valid ri pointer but dangling rs pointer.
Previously, the IV and key were stored in the structure, even though
they mostly weren't needed. The only purpose they had was to
support a seldom-used API where you could pass NULL when creating
a cipher in order to get a random key/IV, and then pull that key/IV
back out.
This saves 32 bytes per AES instance, and makes it easier to support
different key lengths.
* Check consistency between the two single onion torrc options
* Use the more relevant option each time we check for single onion mode
* Clarify log messages
* Clarify comments
* Otherwise, no behaviour change
Tor checks that the flag matches the configured onion service anonymity.
Tor refuses to create unflagged onion service using ADD_ONION, if they
would be non-anonymous. The error is:
512 Tor is in non-anonymous onion mode
Similarly, if the NonAnonymous flag is present, and Tor has the default
anonymous onion config:
512 Tor is in anonymous onion mode
Parse the value to UseEntryNodes_option, then set UseEntryNodes before
validating options.
This way, Authorities, Tor2web, and Single Onion Services don't write
spurious "UseEntryNodes 0" lines to their configs. Document the fact that
these tor configurations ignore UseEntryNodes in the manual page.
Also reorder options validation so we modify UseEntryNodes first, then
check its value against EntryNodes.
And silence a warning about disabled UseEntryNodes for hidden services
when we're actually in non-anonymous single onion service mode.
We log this message every time we validate tor's options.
There's no need to log a duplicate in main() as well.
(It is impossible to run main() without validating our options.)
The changes in #19973 fixed ReachableAddresses being applied
too broadly, but they also broke Tor2web (somewhat unintentional)
compatibility with ReachableAddresses.
This patch restores that functionality, which makes intro and
rend point selection is consistent between Tor2web and Single Onion
Services.
Add experimental OnionServiceSingleHopMode and
OnionServiceNonAnonymousMode options. When both are set to 1, every
hidden service on a tor instance becomes a non-anonymous Single Onion
Service. Single Onions make one-hop (direct) connections to their
introduction and renzedvous points. One-hop circuits make Single Onion
servers easily locatable, but clients remain location-anonymous.
This is compatible with the existing hidden service implementation, and
works on the current tor network without any changes to older relays or
clients.
Implements proposal #260, completes ticket #17178. Patch by teor & asn.
squash! fixup! fixup! fixup! fixup! fixup! fixup! fixup! fixup! fixup! fixup! fixup! fixup! fixup! Implement Prop #260: Single Onion Services
Redesign single onion service poisoning.
When in OnionServiceSingleHopMode, each hidden service key is poisoned
(marked as non-anonymous) on creation by creating a poison file in the
hidden service directory.
Existing keys are considered non-anonymous if this file exists, and
anonymous if it does not.
Tor refuses to launch in OnionServiceSingleHopMode if any existing keys
are anonymous. Similarly, it refuses to launch in anonymous client mode
if any existing keys are non-anonymous.
Rewrite the unit tests to match and be more comprehensive.
Adds a bonus unit test for rend_service_load_all_keys().
(We check consensus method when deciding whether to assume a node is
valid. No need to check the consensus method for Running, since
we will never see a method before 13.)
Closes ticket 20001
g
The other test vectors are pretty complete, and get full coverage, I
believe.
This one test vector accounted for half the time spent in
test-slow. "Now that's slow!"
We have a mock for our RSA key generation function, so we now wire
it to pk_generate(). This covers all the cases that were not using
pk_generate() before -- all ~93 of them.
Previously, you needed to store the previous log severity in a local
variable, and it wasn't clear if you were allowed to call these
functions more than once.
The functions it warns about are:
assert, memcmp, strcat, strcpy, sprintf, malloc, free, realloc,
strdup, strndup, calloc.
Also, fix a few lingering instances of these in the code. Use other
conventions to indicate _intended_ use of assert and
malloc/realloc/etc.
We should consider them bugs. If they are happening intentionally,
we should use the log_test_helpers code to capture and suppress
them. But having them off-by-default has potential to cause
programming errors.
Previously setup_capture_of_logs would prevent log messages from
going to the console entirely. That's a problem, since sometimes
log messages are bugs! Now setup_capture_of_logs() acts sensibly.
If you really do need to keep a message from going to the console
entirely, there is setup_full_capture_of_logs(). But only use that
if you're prepared to make sure that there are no extraneous
messages generated at all.
Users can't run an anonymous client and non-anonymous single
onion service at the same time. We need to know whether we have
any client ports or sockets open to do this check.
When determining whether a client port (SOCKS, Trans, NATD, DNS)
is set, count unix sockets when counting client listeners. This
has no user-visible behaviour change, because these options are
set once and never read in the current tor codebase.
Don't count sockets when setting ControlPort_set, that's what
ControlSocket is for. (This will be reviewed in #19665.)
Don't count sockets when counting server listeners, because the code
that uses these options expects to count externally-visible ports.
(And it would change the behaviour of Tor.)
Copying the integer 42 in a char buffer has a different representation
depending on the endianess of the system thus that unit test was failing on
big endian system.
This commit introduces a python script, like the one we have for SRV, that
computes a COMMIT/REVEAL from scratch so we can use it as a test vector for
our encoding unit tests.
With this, we use a random value of bytes instead of a number fixing the
endianess issue and making the whole test case more solid with an external
tool that builds the COMMIT and REVEAL according to the spec.
Fixes#19977
Signed-off-by: David Goulet <dgoulet@torproject.org>
Check NoOnionTraffic before attaching a stream.
NoOnionTraffic refuses connections to all onion hostnames,
but permits non-onion hostnames and IP addresses.
Check NoDNSRequest, NoIPv4Traffic, and NoIPv6Traffic before
attaching a stream.
NoDNSRequest refuses connections to all non-onion hostnames,
but permits IP addresses.
NoIPv4Traffic refuses connections to IPv4 addresses, but resolves
hostnames.
NoIPv6Traffic refuses connections to IPv6 addresses, but resolves
hostnames.
Combined, they refuse all non-onion hostnames and IP addresses.
OnionTrafficOnly is equivalent to NoDNSRequest, NoIPv4Traffic,
and NoIPv6Traffic.
Add unit tests for parsing and checking option validity.
Add documentation for each flag to the man page.
Add changes file for all of #18693.
Parsing only: the flags do not change client behaviour (yet!)
Rely on onion_populate_cpath to check that we're only using
TAP for the rare hidden service cases.
Check and log if handshakes only support TAP when they should support
ntor.
When a client connects to an intro point not in the client's consensus,
or a hidden service connects to a rend point not in the hidden service's
consensus, we are stuck with using TAP, because there is no ntor link
specifier.
This bug had existed since 0.2.4.7-alpha, but now that we have
FallbackDirs by default, it actually matters.
Fixes bug 19947; bugfix on 0.2.4.7-alpha or maybe 0.2.8.1-alpha.
Rubiate wrote the patch; teor wrote the changes file.
Longer and more explicit log message so we don't confuse users with behind NAT with working configurations and state that public IP addresses only should be provided with "Address", won't work with internal addresses.
OpenBSD removes this function, and now that Tor requires Libevent 2,
we should also support the OpenBSD Libevent 2.
Fixes bug 19904; bugfix on 0.2.5.4-alpha.
These functions were there so that we could abstract the differences
between evbuffer and buf_t. But with the bufferevent removal, this
no longer serves a purpose.
To maintain precision, to get nanoseconds, we were multiplying our
tick count by a billion, then dividing by ticks-per-second. But
that apparently isn't such a great idea, since ticks-per-second is
sometimes a billion on its own, so our intermediate result was
giving us attoseconds.
When you're counting in attoseconds, you can only fit about 9
seconds into an int64_t, which is not so great for our purposes.
Instead, we now simplify the 1000000000/1000000000 fraction before
we start messing with nanoseconds. This has potential to mess us
up if some future MS version declares that performance counters will
use 1,000,000,007 units per second, but let's burn that bridge when
we come to it.
* Raise limit: 16k isn't all that high.
* Don't log when limit exceded; log later on.
* Say "over" when we log more than we say we log.
* Add target version to changes file
This code uses QueryPerformanceCounter() [**] on Windows,
mach_absolute_time() on OSX, clock_gettime() where available, and
gettimeofday() [*] elsewhere.
Timer types are stored in an opaque OS-specific format; the only
supported operation is to compute the difference between two timers.
[*] As you know, gettimeofday() isn't monotonic, so we include
a simple ratchet function to ensure that it only moves forward.
[**] As you may not know, QueryPerformanceCounter() isn't actually
always as monotonic as you might like it to be, so we ratchet that
one too.
We also include a "coarse monotonic timer" for cases where we don't
actually need high-resolution time. This is GetTickCount{,64}() on
Windows, clock_gettime(CLOCK_MONOTONIC_COARSE) on Linux, and falls
back to regular monotonic time elsewhere.
If we know a node's version, and it can't do ntor, consider it not running.
If we have a node's descriptor, and it doesn't have a valid ntor key,
consider it not running.
Refactor these checks so they're consistent between authorities and clients.
Before, they checked for version 0.2.4.18-rc or later, but this
would not catch relays without version lines, or buggy or malicious
relays missing an ntor key.
If we did not find a non-private IPaddress by iterating over interfaces,
we would try to get one via
get_interface_address6_via_udp_socket_hack(). This opens a datagram
socket with IPPROTO_UDP. Previously all our datagram sockets (via
libevent) used IPPROTO_IP, so we did not have that in the sandboxing
whitelist. Add (SOCK_DGRAM, IPPROTO_UDP) sockets to the sandboxing
whitelist. Fixes bug 19660.
This fixes#19608, allowing IPv6-only clients to use
microdescriptors, while preserving the ability of bridge clients
to have some IPv4 bridges and some IPv6 bridges.
Fix on c281c036 in 0.2.8.2-alpha.
The test was checking for EISDIR which is a Linux-ism making other OSes
unhappy. Instead of checking for a negative specific errno value, just make
sure it's negative indicating an error. We don't need more for this test.
Signed-off-by: David Goulet <dgoulet@torproject.org>
We introduded a shadowed variable, thereby causing a log message to
be wrong. Fixes 19578. I believe the bug was introduced by
54d7d31cba in 0.2.2.29-beta.
I grepped and hand-inspected the "it's" instances, to see if any
were supposed to be possessive. While doing that, I found a
"the the", so I grepped to see if there were any more.
Keep the base16 representation of the RSA identity digest in the commit object
so we can use it without using hex_str() or dynamically encoding it everytime
we need it. It's used extensively in the logs for instance.
Fixes#19561
Signed-off-by: David Goulet <dgoulet@torproject.org>
Encoded commit has an extra byte at the end for the NUL terminated byte and
the test was overrunning the payload buffer by one byte.
Found by Coverity issue 1362984.
Fixes#19567
Signed-off-by: David Goulet <dgoulet@torproject.org>
This patch also updates a comment in the same function for accuracy.
Found by Coverity issue 1362985. Partily fixes#19567.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Only some very ancient distributions don't ship with Libevent 2 anymore,
even the oldest supported Ubuntu LTS version has it. This allows us to
get rid of a lot of compat code.
Our sandboxing code would not allow us to write to stats/hidserv-stats,
causing tor to abort while trying to write stats. This was previously
masked by bug#19556.
When sandboxing is enabled, we could not write any stats to disk.
check_or_create_data_subdir("stats"), which prepares the private stats
directory, calls check_private_dir(), which also opens and not just stats() the
directory. Therefore, we need to also allow open() for the stats dir in our
sandboxing setup.
The test_state_update() test would fail if you run it between 23:30 and
00:00UTC in the following line because n_protocol_runs was 2:
tt_u64_op(state->n_protocol_runs, ==, 1);
The problem is that when you launch the test at 23:30UTC (reveal phase),
sr_state_update() gets called from sr_state_init() and it will prepare
the state for the voting round at 00:00UTC (commit phase). Since we
transition from reveal to commit phase, this would trigger a phase
transition and increment the n_protocol_runs counter.
The solution is to initialize the n_protocol_runs to 0 explicitly in the
beginning of the test, as we do for n_reveal_rounds, n_commit_rounds etc.
The *get* state query functions for the SRVs now only return const pointers
and the DEL action needs to be used to delete the SRVs from the state.
Signed-off-by: David Goulet <dgoulet@torproject.org>
This patch makes us retain the intermediate list of K=V entries for
the duration of computing our vote, and lets us use that list with
a new function in order to look up parameters before the consensus
is published.
We can't actually use this function yet because of #19011: our
existing code to do this doesn't actually work, and we'll need a new
consensus method to start using it.
Closes ticket #19012.
Commit and reveal length macro changed from int to unsigned long int
(size_t) because of the sizeof().
Signed-off-by: David Goulet <dgoulet@torproject.org>
See ticket #19132 for the clang/llvm warning.
Since voting_schedule is a global static struct, it will be initialized
to zero even without explicitly initializing it with {0}.
This is what the C spec says:
If an object that has automatic storage duration is not initialized
explicitly, its value is indeterminate. If an object that has static
storage duration is not initialized explicitly, then:
— if it has pointer type, it is initialized to a null pointer;
— if it has arithmetic type, it is initialized to (positive or unsigned) zero;
— if it is an aggregate, every member is initialized (recursively) according to these rules;
— if it is a union, the first named member is initialized (recursively) according to these rules.
Code has been changed so every RSA fingerprint for a commit in our state is
validated before being used. This fixes the unit tests by mocking one of the
key function and updating the hardcoded state string.
Also, fix a time parsing overflow on platforms with 32bit time_t
Signed-off-by: David Goulet <dgoulet@torproject.org>
Signed-off-by: George Kadianakis <desnacked@riseup.net>
We assert on it using the ASSERT_COMMIT_VALID() macro in critical places
where we use them expecting a commit to be valid.
Signed-off-by: David Goulet <dgoulet@torproject.org>
The prop250 code used the RSA identity key fingerprint to index commit in a
digestmap instead of using the digest.
To behavior change except the fact that we are actually using digestmap
correctly.
Signed-off-by: David Goulet <dgoulet@torproject.org>
This commit makes it that tor now uses the shared random protocol by
initializing the subsystem.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Signed-off-by: George Kadianakis <desnacked@riseup.net>
One of the last piece that parses the votes and consensus in order to update
our state and make decision for the SR values.
We need to inform the SR subsystem when we set the current consensus because
this can be called when loaded from file or downloaded from other authorities
or computed.
The voting schedule is used for the SR timings since we are bound to the
voting system.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Signed-off-by: George Kadianakis <desnacked@riseup.net>
This commit adds the commit(s) line in the vote as well as the SR values. It
also has the mechanism to add the majority SRVs in the consensus.
Signed-off-by: George Kadianakis <desnacked@riseup.net>
Signed-off-by: David Goulet <dgoulet@torproject.org>
This adds the logic of commit and SR values generation. Furthermore, the
concept of a protocol run is added that is commit is generated at the right
time as well as SR values which are also rotated before a new protocol run.
Signed-off-by: George Kadianakis <desnacked@riseup.net>
Signed-off-by: David Goulet <dgoulet@torproject.org>
From 0.2.7.2-alpha onwards, Exits would reject all the IP addresses
they knew about in their exit policy. But this may have disclosed
addresses that were otherwise unlisted.
Now, only advertised addresses are rejected by default by
ExitPolicyRejectPrivate. All known addresses are only rejected when
ExitPolicyRejectLocalInterfaces is explicitly set to 1.
