Failure to do so left us open to a remotely triggerable assertion
failure. Fixes CVE-2012-2249; bugfix on 0.2.3.6-alpha. Reported by
"some guy from France".
This patch is a forward-port to 0.2.4, to work with the new channel
logic.
Failure to do so left us open to a remotely triggerable assertion
failure. Fixes CVE-2012-2249; bugfix on 0.2.3.6-alpha. Reported by
"some guy from France".
We were calling channel_get_actual_remote_descr() before we used the
output of a previous channel_get_canonical_remote_descr(), thus
invalidating its output.
When we merged the channel code, we made the 'address' field of linked
directory connections created with begindir (and their associated edge
connections) contain an address:port string, when they should only
have contained the address part.
This patch also tweaks the interface to the get_descr method of
channels so that it takes a set of flags rather than a single flag.
In 4768c0efe3 (not in any released
version of Tor), we removed a little block of code that set the addr
field of an exit connection used in making a tunneled directory
request. Turns out that wasn't right.
In C, we technically aren't supposed to define our own things that
start with an underscore.
This is a purely machine-generated commit. First, I ran this script
on all the headers in src/{common,or,test,tools/*}/*.h :
==============================
use strict;
my %macros = ();
my %skipped = ();
FILE: for my $fn (@ARGV) {
my $f = $fn;
if ($fn !~ /^\.\//) {
$f = "./$fn";
}
$skipped{$fn} = 0;
open(F, $fn);
while (<F>) {
if (/^#ifndef ([A-Za-z0-9_]+)/) {
$macros{$fn} = $1;
next FILE;
}
}
}
print "#!/usr/bin/perl -w -i -p\n\n";
for my $fn (@ARGV) {
if (! exists $macros{$fn}) {
print "# No macro known for $fn!\n" if (!$skipped{$fn});
next;
}
if ($macros{$fn} !~ /_H_?$/) {
print "# Weird macro for $fn...\n";
}
my $goodmacro = uc $fn;
$goodmacro =~ s#.*/##;
$goodmacro =~ s#[\/\-\.]#_#g;
print "s/(?<![A-Za-z0-9_])$macros{$fn}(?![A-Za-z0-9_])/TOR_${goodmacro}/g;\n"
}
==============================
It produced the following output, which I then re-ran on those same files:
==============================
s/(?<![A-Za-z0-9_])_TOR_ADDRESS_H(?![A-Za-z0-9_])/TOR_ADDRESS_H/g;
s/(?<![A-Za-z0-9_])_TOR_AES_H(?![A-Za-z0-9_])/TOR_AES_H/g;
s/(?<![A-Za-z0-9_])_TOR_COMPAT_H(?![A-Za-z0-9_])/TOR_COMPAT_H/g;
s/(?<![A-Za-z0-9_])_TOR_COMPAT_LIBEVENT_H(?![A-Za-z0-9_])/TOR_COMPAT_LIBEVENT_H/g;
s/(?<![A-Za-z0-9_])_TOR_CONTAINER_H(?![A-Za-z0-9_])/TOR_CONTAINER_H/g;
s/(?<![A-Za-z0-9_])_TOR_CRYPTO_H(?![A-Za-z0-9_])/TOR_CRYPTO_H/g;
s/(?<![A-Za-z0-9_])TOR_DI_OPS_H(?![A-Za-z0-9_])/TOR_DI_OPS_H/g;
s/(?<![A-Za-z0-9_])_TOR_MEMAREA_H(?![A-Za-z0-9_])/TOR_MEMAREA_H/g;
s/(?<![A-Za-z0-9_])_TOR_MEMPOOL_H(?![A-Za-z0-9_])/TOR_MEMPOOL_H/g;
s/(?<![A-Za-z0-9_])TOR_PROCMON_H(?![A-Za-z0-9_])/TOR_PROCMON_H/g;
s/(?<![A-Za-z0-9_])_TOR_TORGZIP_H(?![A-Za-z0-9_])/TOR_TORGZIP_H/g;
s/(?<![A-Za-z0-9_])_TOR_TORINT_H(?![A-Za-z0-9_])/TOR_TORINT_H/g;
s/(?<![A-Za-z0-9_])_TOR_LOG_H(?![A-Za-z0-9_])/TOR_TORLOG_H/g;
s/(?<![A-Za-z0-9_])_TOR_TORTLS_H(?![A-Za-z0-9_])/TOR_TORTLS_H/g;
s/(?<![A-Za-z0-9_])_TOR_UTIL_H(?![A-Za-z0-9_])/TOR_UTIL_H/g;
s/(?<![A-Za-z0-9_])_TOR_BUFFERS_H(?![A-Za-z0-9_])/TOR_BUFFERS_H/g;
s/(?<![A-Za-z0-9_])_TOR_CHANNEL_H(?![A-Za-z0-9_])/TOR_CHANNEL_H/g;
s/(?<![A-Za-z0-9_])_TOR_CHANNEL_TLS_H(?![A-Za-z0-9_])/TOR_CHANNELTLS_H/g;
s/(?<![A-Za-z0-9_])_TOR_CIRCUITBUILD_H(?![A-Za-z0-9_])/TOR_CIRCUITBUILD_H/g;
s/(?<![A-Za-z0-9_])_TOR_CIRCUITLIST_H(?![A-Za-z0-9_])/TOR_CIRCUITLIST_H/g;
s/(?<![A-Za-z0-9_])_TOR_CIRCUITMUX_EWMA_H(?![A-Za-z0-9_])/TOR_CIRCUITMUX_EWMA_H/g;
s/(?<![A-Za-z0-9_])_TOR_CIRCUITMUX_H(?![A-Za-z0-9_])/TOR_CIRCUITMUX_H/g;
s/(?<![A-Za-z0-9_])_TOR_CIRCUITUSE_H(?![A-Za-z0-9_])/TOR_CIRCUITUSE_H/g;
s/(?<![A-Za-z0-9_])_TOR_COMMAND_H(?![A-Za-z0-9_])/TOR_COMMAND_H/g;
s/(?<![A-Za-z0-9_])_TOR_CONFIG_H(?![A-Za-z0-9_])/TOR_CONFIG_H/g;
s/(?<![A-Za-z0-9_])TOR_CONFPARSE_H(?![A-Za-z0-9_])/TOR_CONFPARSE_H/g;
s/(?<![A-Za-z0-9_])_TOR_CONNECTION_EDGE_H(?![A-Za-z0-9_])/TOR_CONNECTION_EDGE_H/g;
s/(?<![A-Za-z0-9_])_TOR_CONNECTION_H(?![A-Za-z0-9_])/TOR_CONNECTION_H/g;
s/(?<![A-Za-z0-9_])_TOR_CONNECTION_OR_H(?![A-Za-z0-9_])/TOR_CONNECTION_OR_H/g;
s/(?<![A-Za-z0-9_])_TOR_CONTROL_H(?![A-Za-z0-9_])/TOR_CONTROL_H/g;
s/(?<![A-Za-z0-9_])_TOR_CPUWORKER_H(?![A-Za-z0-9_])/TOR_CPUWORKER_H/g;
s/(?<![A-Za-z0-9_])_TOR_DIRECTORY_H(?![A-Za-z0-9_])/TOR_DIRECTORY_H/g;
s/(?<![A-Za-z0-9_])_TOR_DIRSERV_H(?![A-Za-z0-9_])/TOR_DIRSERV_H/g;
s/(?<![A-Za-z0-9_])_TOR_DIRVOTE_H(?![A-Za-z0-9_])/TOR_DIRVOTE_H/g;
s/(?<![A-Za-z0-9_])_TOR_DNS_H(?![A-Za-z0-9_])/TOR_DNS_H/g;
s/(?<![A-Za-z0-9_])_TOR_DNSSERV_H(?![A-Za-z0-9_])/TOR_DNSSERV_H/g;
s/(?<![A-Za-z0-9_])TOR_EVENTDNS_TOR_H(?![A-Za-z0-9_])/TOR_EVENTDNS_TOR_H/g;
s/(?<![A-Za-z0-9_])_TOR_GEOIP_H(?![A-Za-z0-9_])/TOR_GEOIP_H/g;
s/(?<![A-Za-z0-9_])_TOR_HIBERNATE_H(?![A-Za-z0-9_])/TOR_HIBERNATE_H/g;
s/(?<![A-Za-z0-9_])_TOR_MAIN_H(?![A-Za-z0-9_])/TOR_MAIN_H/g;
s/(?<![A-Za-z0-9_])_TOR_MICRODESC_H(?![A-Za-z0-9_])/TOR_MICRODESC_H/g;
s/(?<![A-Za-z0-9_])_TOR_NETWORKSTATUS_H(?![A-Za-z0-9_])/TOR_NETWORKSTATUS_H/g;
s/(?<![A-Za-z0-9_])_TOR_NODELIST_H(?![A-Za-z0-9_])/TOR_NODELIST_H/g;
s/(?<![A-Za-z0-9_])_TOR_NTMAIN_H(?![A-Za-z0-9_])/TOR_NTMAIN_H/g;
s/(?<![A-Za-z0-9_])_TOR_ONION_H(?![A-Za-z0-9_])/TOR_ONION_H/g;
s/(?<![A-Za-z0-9_])_TOR_OR_H(?![A-Za-z0-9_])/TOR_OR_H/g;
s/(?<![A-Za-z0-9_])_TOR_POLICIES_H(?![A-Za-z0-9_])/TOR_POLICIES_H/g;
s/(?<![A-Za-z0-9_])_TOR_REASONS_H(?![A-Za-z0-9_])/TOR_REASONS_H/g;
s/(?<![A-Za-z0-9_])_TOR_RELAY_H(?![A-Za-z0-9_])/TOR_RELAY_H/g;
s/(?<![A-Za-z0-9_])_TOR_RENDCLIENT_H(?![A-Za-z0-9_])/TOR_RENDCLIENT_H/g;
s/(?<![A-Za-z0-9_])_TOR_RENDCOMMON_H(?![A-Za-z0-9_])/TOR_RENDCOMMON_H/g;
s/(?<![A-Za-z0-9_])_TOR_RENDMID_H(?![A-Za-z0-9_])/TOR_RENDMID_H/g;
s/(?<![A-Za-z0-9_])_TOR_RENDSERVICE_H(?![A-Za-z0-9_])/TOR_RENDSERVICE_H/g;
s/(?<![A-Za-z0-9_])_TOR_REPHIST_H(?![A-Za-z0-9_])/TOR_REPHIST_H/g;
s/(?<![A-Za-z0-9_])_TOR_REPLAYCACHE_H(?![A-Za-z0-9_])/TOR_REPLAYCACHE_H/g;
s/(?<![A-Za-z0-9_])_TOR_ROUTER_H(?![A-Za-z0-9_])/TOR_ROUTER_H/g;
s/(?<![A-Za-z0-9_])_TOR_ROUTERLIST_H(?![A-Za-z0-9_])/TOR_ROUTERLIST_H/g;
s/(?<![A-Za-z0-9_])_TOR_ROUTERPARSE_H(?![A-Za-z0-9_])/TOR_ROUTERPARSE_H/g;
s/(?<![A-Za-z0-9_])TOR_ROUTERSET_H(?![A-Za-z0-9_])/TOR_ROUTERSET_H/g;
s/(?<![A-Za-z0-9_])TOR_STATEFILE_H(?![A-Za-z0-9_])/TOR_STATEFILE_H/g;
s/(?<![A-Za-z0-9_])_TOR_STATUS_H(?![A-Za-z0-9_])/TOR_STATUS_H/g;
s/(?<![A-Za-z0-9_])TOR_TRANSPORTS_H(?![A-Za-z0-9_])/TOR_TRANSPORTS_H/g;
s/(?<![A-Za-z0-9_])_TOR_TEST_H(?![A-Za-z0-9_])/TOR_TEST_H/g;
s/(?<![A-Za-z0-9_])_TOR_FW_HELPER_H(?![A-Za-z0-9_])/TOR_TOR_FW_HELPER_H/g;
s/(?<![A-Za-z0-9_])_TOR_FW_HELPER_NATPMP_H(?![A-Za-z0-9_])/TOR_TOR_FW_HELPER_NATPMP_H/g;
s/(?<![A-Za-z0-9_])_TOR_FW_HELPER_UPNP_H(?![A-Za-z0-9_])/TOR_TOR_FW_HELPER_UPNP_H/g;
==============================
The rationale for treating these files differently is that we should
be checking upstream for changes as applicable, and merging changes
upstream as warranted.
Conflicts:
src/or/circuitbuild.c
The conflict was trivial, since no line of code actually changed in
both branches: There was a fmt_addr() that turned into fmt_addrport()
in bug7011, and a "if (!n_conn)" that turned into "if (!n_chan)" in
master.
This is mostly a conversion from this pattern:
log("... %s:%d ...", fmt_and_decorate_addr(&addr), port);
to this:
log("... %s ...", fmt_addrport(&addr, port));
The output is the same in all cases.
Apparently BridgeDB is already expecting transport lines to be formatted
thus; see https://trac.torproject.org/projects/tor/ticket/7011#comment:12 ff.
It may be that there are no extant IPv6 pluggable transport bridges yet,
so this didn't cause a problem.
state_transport_line_is_valid calls tor_addr_port_lookup, which expects
brackets around an IPv6 address. Without this, cached transport
addresses can't be parsed later:
[warn] state: Could not parse addrport.
[warn] state: State file seems to be broken.
See #7011.
It's possible for connection_or_connect() to fail and return NULL after it
sets tlschan->conn, so not checking leaves a channel hanging around in
CHANNEL_STATE_OPENING with a pointer to a freed or_connection_t forever.
Note: this is a squashed commit; see branch bug6465_rebased_v2 of user/andrea/tor.git for full history of the following 2 commits:
Use channel_t in cpuworker.c
Fix bug in channel_t usage in cpuworker.c that was killing relaying on channel_t-ized Tor. The tags passed to the worker now have a channel ID, not a connection ID.
Note: this is a squashed commit; see branch bug6465_rebased_v2 of user/andrea/tor.git for full history of the following 10 commits:
Convert relay.c/relay.h to channel_t
Updating the timestamp if n_flushed > 0 at the end of channel_flush_from_first_active_circuit() was redundant since channel_write_cell() et al. do it themselves.
Get rid of now-unnecessary time parameter in channel_flush_from_first_active_circuit()
Get rid of now-unnecessary time parameter in channel_flush_from_first_active_circuit() in connection_or.c
Add non-inlined external call for channeltls.c to free a packed_cell_t
Appease make check-spaces in relay.c
Replace channel_get_write_queue_len() with sufficient and easier to implement channel_has_queued_writes() in relay.c
Rename channel_touched_by_client() and client_used field for consistency with other timestamps in relay.c
Don't double-free packed cells in relay.c (channel_t Tor now bootstraps and works as a client)
Rearrange channel_t struct to use a union distinguishing listener from cell-bearing channels in relay.c
Note: this is a squashed commit; see branch bug6465_rebased_v2 of user/andrea/tor.git for full history of the following 90 commits:
Add channel.c/channel.h for bug 6465
Fix make check-spaces in new channel.c/channel.h
Make sure new channel.h is in nodist_HEADERS and Makefile.nmake is up to date too
Add channel_state_t and state utility functions
Add channel_change_state()
Better comments in channel.h
Add CHANNEL_STATE_LISTENING for channel_t
Fix wide line in channel.c
Add structures/prototypes for incoming cell handling
Implement channel_queue_cell() and channel_queue_var_cell()
Implement channel_process_cells()
Fix asserts in channel_queue_cell() and channel_queue_var_cell()
Add descriptive comments for channel_queue_cell() and channel_queue_var_cell()
Implement channel cell handler getters/setters
Queue outgoing writes when not in writeable state
Drain queues and test assertions when changing channel_t state
Add log_debug() messages for channel_t stuff
Add log_debug() messages for channel_t stuff
Add some channel_t metadata
Add time_t client_used to channel_t
Add channel_touched_by_client()
Declare a few channel_t metadata queries we'll have to implement later for use by circuitbuild.c
Add next_circ_id/circ_id_type to channel_t for use by circuitbuild.c
Count n_circuits in channel_t
Channel timestamp calls
Add create timestamp for channel.h
Declare some new metadata queries on channel_t
Add get_real_remote_descr() prototype
Move active_circuits stuff to channel_t, some other or.h and channel.h changes
Make channel_t refcounted and use global lists of active channels
Update channel_request_close() and channel_change_state() for channel_t registration mechanism
Handle closing channels sensibly
Add global_identifier for channels, channel_init() internal use function
Add timestamp_last_added_nonpadding to channel_t
Better comments in channel_init()
Correctly handle next_circ_id in channel_init()
Correctly handle next_circ_id in channel_init() and even compile this time
Appease make check-spaces
Update timestamps when writing cells to channel_t
Add channel_flush_some_cells() to call channel_flush_from_first_active_circuit()
Add registered channel lookup functions
Get rid of client_used in or_connection_t; it's in channel_t now
Get rid of circ_id_type in or_connection_t; implement channel_set_circ_id_type()
Eliminate is_bad_for_new_circs in or_connection_t; implement getter/setter for it in channel_t
Eliminate next_circ_id in or_connection_t in favor of channel_t
Handle packed cells in channel_t for relay.c
Add channel_identity_map and related functions
Handle add/remove from channel identity map on state transitions
Implement channel_is_local() and channel_mark_local()
Implement channel_is_client() and channel_mark_client()
Implement channel_is_outgoing() and channel_mark_outgoing()
Eliminate declaration for redundant channel_nonopen_was_started_here()
Add channel timestamps
Add channel timestamps, fix some make-check-spaces complaints
Remove redundant channel_was_started_here() function and initiated_remotely bit
Rename channel_get_remote_descr()/channel_get_real_remote_descr() to something clearer in channel.h
Replace channel_get_write_queue_len() with sufficient and easier to implement channel_has_queued_writes() in channel.h
Change return type of channel_is_bad_for_new_circs() to int for consistency
Implement channel_has_queued_writes()
Rename channel_touched_by_client() and client_used field for consistency with other timestamps in channel.{c,h}
Implement channel_get_actual_remote_descr() and channel_get_canonical_remote_descr() in channel.{c,h}
Implement channel_matches_extend_info() in channel.{c,h}
Implement channel_get_for_extend() and channel_is_better() in channel.{c,h}
Make channel_is_better() public in channel.{c,h}
Implement channel_matches_target_addr_for_extend() in channel.{c,h}
Implement channel_is_canonical_is_reliable() in channel.{c,h}
Demoronize get_remote_descr() method prototype - what the hell was I thinking there?
Timestamp channels in the right places in channel.c
Add missing tor_assert() in channel.c
Check if the lower layer accepted a cell in channel_write_cell() et al. of channel.c
Implement channel_flush_cells() in channel.c (w00t, it builds at last)
Call channel_timestamp_drained() at the right places in channel.c
Implement channel_run_cleanup()
Support optional channel_get_remote_addr() method and use it for GeoIP in channel_do_open_actions()
Get rid of channel refcounting; it'll be too complicated to handle it properly with all the pointers from circuits to channels, and closing from channel_run_cleanup() will work okay just like with connections
Doxygenate channel.c
Appease make check-spaces in channel.c
Fix superfluous semicolons in channel.c
Add/remove channels from identity digest map in all the right places in channel.c
The cell queues on channel_t must be empty when going to a CLOSED or ERROR state
Appease make check-spaces in channel.c
Add channel_clear/set_identity_digest() and some better logging to channel.{c,h}
Fix better logging to channel.c
Avoid SIGSEGV testing for queue emptiness in channel_flush_some_cells_from_outgoing_queue()
Remove TODO about checking cell queue in channel_free(); no need for it
Appease make check-spaces in channel.c
Add channel_free_all() and support functions
Check nullness of active_circuit_pqueue in channel_free()
Fix SMARTLIST_FOREACH_END usage in channel_process_cells()
Rearrange channel_t struct to use a union distinguishing listener from cell-bearing channels in channel.{c,h}
They're typically redundant with the "Your computer is too slow"
messages. Fixes bug 7038; bugfix on 0.2.2.16-alpha.
(In retrospect, we should have fixed this bug back in ticket 1042.)
We used to never return an IPv6 address unless ClientUseIPv6 was
set. We should allow clients running with bridges use IPv6 OR ports
even without setting ClientUseIPv6. Configuring an IPv6 address in a
Bridge line should imply that.
Fixes th second part of #6757.
Look at the address family of the preferred OR port rather than the
node.ipv6_preferred flag since the logic has changed with new
ClientUseIPv6 config option.
Fixes ticket 6884.
Right-shifting negative values has implementation-defined behavior.
On all the platforms we work on right now, the behavior is to
sign-extend the input. That isn't what we wanted in
auth_type_val = (descriptor_cookie_tmp[16] >> 4) + 1;
Fix for 6861; bugfix on 0.2.1.5-alpha; reported pseudonymously.
The broken behavior didn't actually hurt anything, I think, since the
only way to get sign-extension to happen would be to have the top bit
of descriptor_cookie_tmp[16] set, which would make the value of
descriptor_cookie_tmp[16] >> 4 somewhere between 0b11111111 and
0b11111000 (that is, between -1 and -8). So auth_type_val would be
between -7 and 0. And the immediate next line does:
if (auth_type_val < 1 || auth_type_val > 2) {
So the incorrectly computed auth_type_val would be rejected as
invalid, just as a correctly computed auth_type_val would be.
Still, this stuff shouldn't sit around the codebase.
We were doing (1<<p) to generate a flag at position p, but we should
have been doing (U64_LITERAL(1)<<p).
Fixes bug 6861; bugfix on 0.2.0.3-alpha; reported pseudonymously.
Our flag voting code needs to handle unrecognized flags, so it stores
them in a 64-bit bitfield. But we never actually checked for too many
flags, so we were potentially doing stuff like U64_LITERAL(1)<<flagnum
with flagnum >= 64. That's undefined behavior.
Fix for bug 6833; bugfix on 0.2.0.1-alpha.
When I removed version_supports_begindir, I accidentally removed the
mechanism we had been using to make a directory cache self-test its
directory port. This caused bug 6815, which caused 6814 (both in
0.2.4.2-alpha).
To fix this bug, I'm replacing the "anonymized_connection" argument to
directory_initiate_command_* with an enumeration to say how indirectly
to connect to a directory server. (I don't want to reinstate the
"version_supports_begindir" argument as "begindir_ok" or anything --
these functions already take too many arguments.)
For safety, I made sure that passing 0 and 1 for 'indirection' gives
the same result as you would have gotten before -- just in case I
missed any 0s or 1s.
we can turn it into an autobool later if we have some way for it
to make a decision.
(patch possibly got lost when nickm merged #6770; or maybe nickm meant
for it to be this way. i'm not sure.)
Add handle_fw_helper_output(), a function responsible for parsing the
output of tor-fw-helper. Refactor tor_check_port_forwarding() and
run_scheduled_events() accordingly too.
We now issue warnings when we get control output from tor-fw-helper,
and we log the verbose output of tor-fw-helper in LOG_INFO.
Conflicts:
src/common/util.c
See #4771 for rationale.
Note that this patch does not take suggested changes in #4470 into
account and keeps treating AuthDirHasIPv6Connectivity as an
AUTOBOOL. Thus, bug fixes for that are included here as well.
This is a fix on master, unreleased as of now.
Also, make node_get_prim_orport() indicate in its return value whether
a valid OR port was copied or not.
Maybe we should make it legal to pass ap_out==NULL?
Also, do this only for clients, explicitly.
Also, give the flag a value every time we set consensus. We used to
touch it only when ClientPreferIPv6ORPort was set, which was wrong.
extend_info_from_node() used to use the primary OR port (i.e. IPv4)
unless the node had routerinfo. Now that we have IPv6 addresses in
microdescs we may want to use them.
Note that this patch changes using r->cache_info.identity_digest into
using node->identity. I count on these being well synchronised, or
things would break in other ways. Right?
Add ClientUseIPv6 and ClientPreferIPv6ORPort configuration options.
Use "preferred OR port" for all entry nodes, not only for bridges.
Mark bridges with "prefer IPv6 OR port" if an IPv6 address is
configured in Bridge line and ClientPreferIPv6ORPort is set.
Mark relays with "prefer IPv6 OR port" if an IPv6 address is found in
descriptor and ClientPreferIPv6ORPort is set.
Filter "preferred OR port" through the ClientUseIPv6 config option. We
might want to move this test to where actual connection is being set
up once we have a fall back mechanism in place.
Have only non-servers pick an IPv6 address for the first hop: We
don't want relays to connect over IPv6 yet. (IPv6 has never been used
for second or third hops.)
Implements ticket 5535.
Generate and store all supported microdescriptor formats. Generate
votes with one "m" line for each format. Only "m" lines with version
info matching chosen consensus method will be voted upon.
An optimisation would be to combine "m" lines with identical hashes,
i.e. instead of "m 1,2,3 H1" and "m 4,5 H1", say "m 1,2,3,4,5 H1".
Define new new consensus method 14 adding "a" lines to vote and
consensus documents.
From proposal 186:
As with other data in the vote derived from the descriptor, the
consensus will include whichever set of "a" lines are given by the
most authorities who voted for the descriptor digest that will be
used for the router.
This patch implements this.
Allow one-hop directory fetching circuits the full "circuit build timeout"
period, rather than just half of it, before failing them and marking
the relay down. This fix should help reduce cases where clients declare
relays (or worse, bridges) unreachable because the TLS handshake takes
a few seconds to complete.
Fixes bug 6743 (one piece of bug 3443); bugfix on 0.2.2.2-alpha, where
we changed the timeout from a static 30 seconds.
We've had over two months to fix them, and didn't. Now we need
0.2.3.x stable. Yes, it would be cool to get this working in
0.2.3.x, but not at the expense of delaying every other feature that
_does_ work in 0.2.3.x. We can do a real fix in 0.2.4.
This is important, since otherwise an attacker can use timing info
to probe the internal network.
Also, add an option (ExtendAllowPrivateAddresses) so that
TestingTorNetwork won't break.
Fix for bug 6710; bugfix on all released versions of Tor.
Move extend_info_from_router() from circuitbuild.c to router.c and
make it static.
Add get_configured_bridge_by_orports_digest() and have
get_configured_bridge_by_routerinfo() and
node_is_a_configured_bridge() use it. We now consider all OR ports of
a bridge when looking for it.
Move node_get_*_orport to nodelist.c.
Fix a cut'n'paste error in header of nodelist.h.
Add node_assert_ok().
Add router_get_all_orports(). It's duplicating code from
node_get_all_orports(). Worth fixing at the cost of complicating the
API slightly?
There was some code in the "err:" block that would always log a
warning, reporting an "unknown error" if we hadn't set err_msg. But
there were also plenty of "goto err" blocks that did their own
logging, and never set err_msg at all. Now we should only log when
we have an error message to log.
This fixes bug 6638, from no released Tor version.
Failure to do this would lead to double-free cases and similar,
especially when the exit's DNS was broken. See bug 6472 for full
details; this is a fix for 6472.
Anonymous patch from "cypherpunks" on trac.
Long ago, before we had cell queues, it was necessary to maybe call
connection_handle_write() from connectino_write_to_buf_impl() on OR
connections, so that we wouldn't get into a loop of reading infinite
amounts of data and queueing it all on an outbuf before bothering to
write any data.
If that doesn't sounds like what our code does now, you're right:
right now, we won't stick more than OR_CONN_HIGHWATER bytes of cells
on an outbuf, and we won't suck more than CELL_QUEUE_HIGHWATER_SIZE
cells off any edge connection. So, there's no more call for that
code.
Removing this code will simplify our data flow, and that should be
something we can all get behind.
This is done to avoid spurious warns. Additional log lines are also
added to try to track down the codepaths where we are somehow overcounting
success counts.
This patch extracts the inner part of config_register_addressmaps --
the part that knows about detecting wildcard addresses addresses --
and makes it into a new function. The new function is deliberately
not moved or reindented, so that the diff is smaller.
I need this to fix bug 6244.
Extend cells aren't allowed to have a stream_id, but we were only
blocking them when they had a stream_id that corresponded to a
connection. As far as I can tell, this change is harmless: it will
make some kinds of broken clients not work any more, but afaik nobody
actually make a client that was broken in that way.
Found while hunting for other places where we made the same mistake
as in 6271.
Bugfix on d7f50337c1 back from May 2003, which introduced
telescoping circuit construction into 0.0.2pre8.
Thanks to the changes we started making with SocksPort and friends
in 0.2.3.3-alpha, any of our code that did "if (options->Sockport)"
became wrong, since "SocksPort 0" would make that test true whereas
using the default SocksPort value would make it false. (We didn't
actually do "if (options->SockPort)" but we did have tests for
TransPort. When we moved DirPort, ORPort, and ControlPort over to
the same system in 0.2.3.9-alpha, the problem got worse, since our
code is littered with checks for DirPort and ORPort as booleans.
This code renames the current linelist-based FooPort options to
FooPort_lines, and adds new FooPort_set options which get set at
parse-and-validate time on the or_options_t. FooPort_set is true
iff we will actually try to open a listener of the given type. (I
renamed the FooPort options rather than leave them alone so that
every previous user of a FooPort would need to get inspected, and so
that any new code that forgetfully uses FooPort will need fail to
compile.)
Fix for bug 6507.
With this patch, I dump the old kludge of using magic negative
numbers to indicate unknown bandwidths. I also compute each node's
weighted bandwidth exactly once, rather than computing it once in
a loop to compute the total weighted bandwidth and a second time in
a loop to find which one we picked.
Previously, we had incremented rand_bw so that when we later tested
"tmp >= rand_bw", we wouldn't have an off-by-one error. But instead,
it makes more sense to leave rand_bw alone and test "tmp > rand_bw".
Note that this is still safe. To take the example from the bug1203
writeup: Suppose that we have 3 nodes with bandwidth 1. So the
bandwidth array is { 1, 1, 1 }, and the total bandwidth is 3. We
choose rand_bw == 0, 1, or 2. With the first iteration of the loop,
tmp is now 1; with the second, tmp is 2; with the third, tmp is 3.
Now that our check is tmp > rand_bw, we will set i in the first
iteration of the loop iff rand_bw == 0; in the second iteration of
the loop iff rand_bw == 1, and in the third iff rand_bw == 2.
That's what we want.
Incidentally, this change makes the bug 6538 fix more ironclad: once
rand_bw is set to UINT64_MAX, tmp > rand_bw is obviously false
regardless of the value of tmp.
The old approach, because of its "tmp >= rand_bw &&
!i_has_been_chosen" check, would run through the second part of the
loop slightly slower than the first part. Now, we remove
i_has_been_chosen, and instead set rand_bw = UINT64_MAX, so that
every instance of the loop will do exactly the same amount of work
regardless of the initial value of rand_bw.
Fix for bug 6538.
This should make our preferred solution to #6538 easier to
implement, avoid a bunch of potential nastiness with excessive
int-vs-double math, and generally make the code there a little less
scary.
"But wait!" you say. "Is it really safe to do this? Won't the
results come out differently?"
Yes, but not much. We now round every weighted bandwidth to the
nearest byte before computing on it. This will make every node that
had a fractional part of its weighted bandwidth before either
slighty more likely or slightly less likely. Further, the rand_bw
value was only ever set with integer precision, so it can't
accurately sample routers with tiny fractional bandwidth values
anyway. Finally, doing repeated double-vs-uint64 comparisons is
just plain sad; it will involve an implicit cast to double, which is
never a fun thing.
This gives us a few benefits:
1) make -j clean all
this will start working, as it should. It currently doesn't.
2) increased parallel build
recursive make will max out at number of files in a directory,
non-recursive make doesn't have such a limitation
3) Removal of duplicate information in make files,
less error prone
I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way
that was used was not only deprecated but will be *removed* in the next
major automake release (1.13).... so probably best that we can continue
to bulid tor without requiring old automake.
(see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html )
For more reasons why, see resources such as:
http://miller.emu.id.au/pmiller/books/rmch/
In 0.2.3.18-rc, we started warning on this case while building a
list of missing microdescriptor digests. That turned out to spam
the logs; instead let's warn at parse time.
Partial fix for bug 6404.
The spec requires that every router in a microdesc consensus have an
m line; we weren't obeying that spec.
This creates a new consensus method (13) to allow voting to continue
to work right. Partial fix for bug 6404; fix on 0.2.2.6-alpha.
Test for config option AuthDirPublishIPv6 == 1 rather than for running
as a bridge authority when deciding whether to care or not about IPv6
OR ports in descriptors.
Implements enhancement #6406.
We can end up in dirserv_orconn_tls_done() with a node missing
routerinfo in at least two cases -- command_process_certs_cell() and
connection_or_check_valid_tls_handshake() -- and probably more.
You can say "struct foo_t" as much as you want, but you'd better not
have "typedef struct foo_t foo_t" more than once.
Fix for bug 6416. Bug not in any released version of Tor.
This avoids a possible crash bug in flush_from_first_active_circuit.
Fixes bug 6341; bugfix on 0.2.2.7-alpha.
Bug reported and fixed by a pseudonymous user on IRC.
I only check on circuits, not streams, since bloating your stream
window past the initial circuit window can't help you much.
Also, I compare to CIRCWINDOW_START_MAX so we don't have surprising
races if we lower CIRCWINDOW_START for an experiment.
The SMARTLIST_FOREACH macro is more convenient than BEGIN/END when
you have a nice short loop body, but using it for long bodies makes
your preprocessor tell the compiler that all the code is on the same
line. That causes grief, since compiler warnings and debugger lines
will all refer to that one line.
So, here's a new style rule: SMARTLIST_FOREACH blocks need to be
short.
- Add a changes/ file.
- Make it compile under --enable-gcc-warnings.
- Update the file-level documentation of src/or/transports.c.
- Only update descriptor if at least a managed proxy was configured.
- Add our external IP address to the extra-info descriptor instead of 0.0.0.0.
This could result in bizarre window values. Report and patch
contributed pseudymously. Fixes part of bug 6271. This bug was
introduced before the first Tor release, in svn commit r152.
(bug 6271, part a.)
This reverts commit c32ec9c425.
It turns out the two sides of the circuit don't actually stay in sync,
so it is perfectly normal for the circuit window on the exit relay to
grow to 2000+. We should fix that bug and then reconsider this patch.
I only check on circuits, not streams, since bloating your stream
window past the initial circuit window can't help you much.
Also, I compare to CIRCWINDOW_START_MAX so we don't have surprising
races if we lower CIRCWINDOW_START for an experiment.
We were doing a tor_strclear() on client_keys_str when it might not
even be set.
Fix for bug 6255; bug not in any release of Tor. Thanks to katmagic
for finding this one!
The functions parse_{s,c}method_line() were using
tor_addr_port_lookup() which is capable of doing DNS lookups. DNS
lookups should not be necessary when parsing {C,S}METHOD lines.
We now catch bare {s that should be on the previous line with a do,
while, if, or for, and elses that should share a line with their
preceding }.
That is,
if (foo)
{
and
if (foo) {
...
}
else
are now detected.
We should think about maybe making Tor uncrustify-clean some day,
but configuring uncrustify is an exercise in bizarreness, and
reformatting huge gobs of Tor is always painful.
The code that detected the source of a remapped address checked that
an address mapping's source was a given rewrite rule if addr_orig had
no .exit, and addr did have a .exit after processing that rule. But
addr_orig was formatted for logging: it was not the original address
at all, but rather was the address escaped for logging and possibly
replaced with "[scrubbed]".
This new logic will correctly set ADDRMAPSRC_NONE in the case when the
address starts life as a .exit address, so that AllowDotExit can work
again.
Fixes bug 6211; bugfix on 0.2.3.17-beta
It turns out this can happen. Even though there is no reason for
connections to be marked but reading, we leave them reading anyway,
so warning here is unwarranted. Let's turn that back on once we do
something sensible and disable reading when we mark. Bugfix for
6203 on Tor 0.2.3.17-beta.
Thanks to cypherpunks for pointing out the general stupidity of the
original code here.
Now it's an orthodox "goto err/done" exit path, and it isn't some
screwy thing where we stick err/done at the end of a loop and
duplicate our cleanup code.
Previously, a directory would check the latest NS consensus for
having the signatures the client wanted, and use that consensus's
valid_until time to set the HTTP lifetime. With this patch, the
directory looks at NS consensus or the microdesc consensus,
depending on what the client asked for.
I saw 72% on a test run with 26 circuits. 70% might be a little close to the
line. That, or min_circs is too low and we need to be more patient. We still
need to test/simulate more.
The defense counts the circuit failure rate for each guard for the past N
circuits. Failure is defined as the ability to complete a first hop, but not
finish completing the circuit all the way to the exit.
If the failure rate exceeds a certain amount, a notice is emitted.
If it exceeds a greater amount, a warn is emitted and the guard is disabled.
These values are governed by consensus parameters which we intend to tune as
we perform experiments and statistical simulations.
The warning message of validate_pluggable_transports_config() is
superseded by the changes in the warning message of
connection_or_connect() when the proxy credentials can't be found.
There is a bug causing busy loops in Libevent and infinite loops in
the Shadow simulator. A connection that is marked for close, wants
to flush, is held open to flush, but is rate limited (the token
bucket is empty) triggers the bug.
This commit fixes the bug. Details are below.
This currently happens on read and write callbacks when the active
socket is marked for close. In this case, Tor doesn't actually try
to complete the read or write (it returns from those methods when
marked), but instead tries to clear the connection with
conn_close_if_marked(). Tor will not close a marked connection that
contains data: it must be flushed first. The bug occurs when this
flush operation on the marked connection can not occur because the
connection is rate-limited (its write token bucket is empty).
The fix is to detect when rate limiting is preventing a marked
connection from properly flushing. In this case, it should be
flagged as read/write_blocked_on_bandwidth and the read/write events
de-registered from Libevent. When the token bucket gets refilled, it
will check the associated read/write_blocked_on_bandwidth flag, and
add the read/write event back to Libevent, which will cause it to
fire. This time, it will be properly flushed and closed.
The reason that both read and write events are both de-registered
when the marked connection can not flush is because both result in
the same behavior. Both read/write events on marked connections will
never again do any actual reads/writes, and are only useful to
trigger the flush and close the connection. By setting the
associated read/write_blocked_on_bandwidth flag, we ensure that the
event will get added back to Libevent, properly flushed, and closed.
Why is this important? Every Shadow event occurs at a discrete time
instant. If Tor does not properly deregister Libevent events that
fire but result in Tor essentially doing nothing, Libevent will
repeatedly fire the event. In Shadow this means infinite loop,
outside of Shadow this means wasted CPU cycles.
From what I can tell, this configuration is usually a mistake, and
leads people to think that all their traffic is getting proxied when
in fact practically none of it is. Resolves the issue behind "bug"
4663.
The function is not guaranteed to NUL-terminate its output. It
*is*, however, guaranteed not to generate more than two bytes per
multibyte character (plus terminating nul), so the general approach
I'm taking is to try to allocate enough space, AND to manually add a
NUL at the end of each buffer just in case I screwed up the "enough
space" thing.
Fixes bug 5909.
This feature can make Tor relays less identifiable by their use of the
mod_ssl DH group, but at the cost of some usability (#4721) and bridge
tracing (#6087) regressions.
We should try to turn this on by default again if we find that the
mod_ssl group is uncommon and/or we move to a different DH group size
(see #6088). Before we can do so, we need a fix for bugs #6087 and
Resolves ticket #5598 for now.
These stats are currently discarded, but we might as well
hard-disable them on bridges, to be clean.
Fix for bug 5824; bugfix on 0.2.1.17-rc.
Patch originally by Karsten Loesing.
Also, try to resolve some doxygen issues. First, define a magic
"This is doxygen!" macro so that we take the correct branch in
various #if/#else/#endifs in order to get the right documentation.
Second, add in a few grouping @{ and @} entries in order to get some
variables and fields to get grouped together.
This code shouldn't have any effect in 0.2.3, since we already accept
(and handle) data received while we are expecting a renegotiation.
(That's because the 0.2.3.x handshake _does_ have data there instead of
the renegotiation.)
I'm leaving it in anyway, since if it breaks anything, we'll want it
broken in master too so we can find out about it. I added an XXX023
comment so that we can come back later and fix that.
This fixes a DoS issue where a client could send so much data in 5
minutes that they exhausted the server's RAM. Fix for bug 5934 and
6007. Bugfix on 0.2.0.20-rc, which enabled the v2 handshake.
This solves bug 5283, where client traffic could get sent over the
same circuit as an anonymized connection to a directory, even if
that circuit used an exit node unsuitable for clients. By marking
the directory connection as needs_internal, we ensure that the
(non-internal!) client-traffic connection won't be sent over the
same circuit.
On Windows, getsockname() on a nonblocking apparently won't work
until the connection is done connecting. On XP, it seems to fail by
reporting success and declaring that your address is INADDR_ANY. On the
Win8 preview, though, it fails more loudly and says WSAEINVAL.
Fix for bug 5374; bugfix on 0.1.1.14-alpha.
Roger explains at
http://archives.seul.org/tor/talk/Nov-2011/msg00209.html :
"If you list your bridge as part of your family in the relay
descriptor, then everybody can learn your bridge fingerprint, and
they can look up your bridge's descriptor (and thus location) at
the bridge directory authority."
Now, we can't stop relays from listing bridges, but we can warn when
we notice a bridge listing anybody, which might help some.
This fixes bug 4657; it's a fix on 0.2.0.3-alpha, where bridges were
first introduced.
To hit this leak, you need to be a relay that gets a RESOLVE request
or an exit node getting a BEGIN or RESOLVE request. You must either
have unconfigured (and unconfigurable) nameservers, or you must have
somehow set DisableNetwork after a network request arrived but
before you managed to process it.
So, I doubt this is reached often. Still, a leak's a leak. Fix for
bug 5916; bugfix on 0.2.3.9-alpha and 0.1.2.1-alpha.
%f is correct; %lf is only needed with scanf. Apparently, on some
old BSDs, %lf is deprecated.
Didn't we do this before? Yes, we did. But we only got the
instances of %lf, not more complicated things like %.5lf . This
patch tries to get everything.
Based on a patch for 3894 by grarpamp.
These errors usually mean address exhaustion; reporting them as such
lets clients adjust their load to try other exits.
Fix for bug 4710; bugfix on 0.1.0.1-rc, which started using
END_STREAM_REASON_RESOURCELIMIT.
Silences the log message:
[warn] {BUG} _connection_mark_unattached_ap(): Bug: stream (marked at connection_edge.c:2224) sending two socks replies?
after the client triggered the "Tor is not an HTTP Proxy" response.
No additional socks reply was sent, though.
Previously, we only did this check at startup, which could lead to
us holding a guard indefinitely, and give weird results. Fixes bug
5380; bugfix on 0.2.1.14-rc.
(Patch by Roger; changes file and commit message by Nick)
Previously, we skipped everything that got invoked from
options_init_from_torrc. But some of the stuff in
options_act_reversible and options_act is actually important, like
reopening the logs.
Now, a SIGHUP always makes the effects of an options_set() happen,
even though the options haven't changed.
Fix for bug 5095; bugfix on 0.2.1.9-alpha, which introduced
__ReloadTorrcOnSIGHUP.
This would happen if the deliver window could become negative
because of an nonexistent connection. (Fortunately, _that_ can't
occur, thanks to circuit_consider_sending_sendme. Still, if we
change our windowing logic at all, we won't want this to become
triggerable.) Fix for bug 5541. Bugfix on 4a66865d, back from
0.0.2pre14. asn found this. Nice catch, asn!
This tells the windows headers to give us definitions that didn't
exist before XP -- like the ones that we need for IPv6 support.
See bug #5861. We didn't run into this issue with mingw, since
mingw doesn't respect _WIN32_WINNT as well as it should for some of
its definitions.
MSVC warns if you declare a function as having a "int foo" argument
and then implement it with a "const int foo" argument, even though
the latter "const" is not a part of the function's interface.
Instead, allow packagers to put a 'TOR_BUILD_TAG' field in the
server descriptor to indicate a platform-specific value, if they
need to. (According to weasel, this was his use for the git- tag
previously.)
This is part of 2988
This time, I follow grarpamp's suggestion and move the check for
.exit+AllowDotExit 0 to the top of connection_ap_rewrite_and_attach,
before any rewriting occurs. This way, .exit addresses are
forbidden as they arrive from a socks connection or a DNSPort
request, and not otherwise.
It _is_ a little more complicated than that, though. We need to
treat any .exit addresses whose source is TrackHostExits as meaning
that we can retry without that exit. We also need to treat any
.exit address that comes from an AutomapHostsOnResolve operation as
user-provided (and thus forbidden if AllowDotExits==0), so that
transitioning from AllowDotExits==1 to AllowDotExits==0 will
actually turn off automapped .exit addresses.
This patch changes the total serverdesc threshold from 25% to 75%
and the exit threshold from 33% to 50%. The goal is to make
initially constructed circuits less horrible, and to make initial
less awful (since fetching directory information in parallel with
whatever the user is trying to do can hurt their performance).
Implements ticket 3196.
We were doing an O(n) strlen in router_get_extrainfo_hash() for
every one we tried to parse. Instead, have
router_get_extrainfo_hash() take the length of the extrainfo as an
argument, so that when it's called from
extrainfo_parse_from_string(), it doesn't do a strlen() over the
whole pile of extrainfos.
If the authorities agreed on a sufficiently bad bwweightscale value
(<=0 or == INT32_MAX), the bandwidth algorithm could make the voters
assert while computing the consensus.
Fix for bug5786; bugfix on 0.2.2.17-alpha
This is how IPv6 says "0.0.0.0" and something we will have to
translate into a globally reachable address before putting it in a
descriptor.
The fix is a short term solution until a real one is implemented.
Closes#5146.
Fixes bug #4528 "read_to_buf_tls(): Inconsistency in code".
This check was added back in 0.1.0.3-rc, but somehow we forgot to
leave it in when we refactored read_to_buf_tls in 0.1.0.5-rc.
(patch by Arturo; commit message and changes file by nickm)
Instead of checking for 'rejected' and calling everything else okay,
let's check for 'outdated' and call everythign else a problem. This
way we don't risk missing future errors so much.
When logging a message that _looks_ like an error message at info, we
should mention that it isn't really a problem.
Previously, we would reset it at the drop of a hat -- every time a second
passes without any of the intro-point circs already launched for the
service failing.
Fixes bug 4607.
