Roger Dingledine:
Tor 0.2.4.13-alpha fixes a variety of potential remote crash vulnerabilities, makes socks5 username/password circuit isolation actually actually work (this time for sure!), and cleans up a bunch of other issues in preparation for a release candidate.
As a heads up, a bug was introduced in this release that allows malicious websites to discover a client's Guard nodes in a very short amount of time (on the order an hour), if those Guard nodes upgrade to this release.
Unfortunately, the bug was introduced by fixing another issue that allows Guard nodes to be selectively DoSed with an OOM condition, so Guard node (and Guard+Exit node) operators are kind of in a jam.
I think the best course of action is to suggest that nodes with the Guard flag *not* upgrade to this release, unless they are experiencing unexplained OOMing?
If we can't find a solution that rigorously fixes both issues, I think that future releases should have the OOM DoS fix off by default but available through a torrc option.
See also: https://trac.torproject.org/projects/tor/ticket/9072
Changes in version 0.2.4.13-alpha - 2013-06-14 o Major bugfixes (robustness): - Close any circuit that has too many cells queued on it. Fixes bug 9063; bugfix on the 54th commit of Tor. This bug is a further fix beyond bug 6252, whose fix was merged into 0.2.3.21-rc. - Prevent the get_freelists() function from running off the end of the list of freelists if it somehow gets an unrecognized allocation. Fixes bug 8844; bugfix on 0.2.0.16-alpha. Reported by eugenis. - Avoid an assertion failure on OpenBSD (and perhaps other BSDs) when an exit connection with optimistic data succeeds immediately rather than returning EINPROGRESS. Fixes bug 9017; bugfix on 0.2.3.1-alpha. - Fix a directory authority crash bug when building a consensus using an older consensus as its basis. Fixes bug 8833. Bugfix on 0.2.4.12-alpha.
o Major bugfixes: - Avoid a memory leak where we would leak a consensus body when we find that a consensus which we couldn't previously verify due to missing certificates is now verifiable. Fixes bug 8719; bugfix on 0.2.0.10-alpha. - We used to always request authority certificates by identity digest, meaning we'd get the newest one even when we wanted one with a different signing key. Then we would complain about being given a certificate we already had, and never get the one we really wanted. Now we use the "fp-sk/" resource as well as the "fp/" resource to request the one we want. Fixes bug 5595; bugfix on 0.2.0.8-alpha. - Follow the socks5 protocol when offering username/password authentication. The fix for bug 8117 exposed this bug, and it turns out real-world applications like Pidgin do care. Bugfix on 0.2.3.2-alpha; fixes bug 8879. - Prevent failures on Windows Vista and later when rebuilding the microdescriptor cache. Diagnosed by Robert Ransom. Fixes bug 8822; bugfix on 0.2.4.12-alpha.
o Minor bugfixes: - Fix an impossible buffer overrun in the AES unit tests. Fixes bug 8845; bugfix on 0.2.0.7-alpha. Found by eugenis. - If for some reason we fail to write a microdescriptor while rebuilding the cache, do not let the annotations from that microdescriptor linger in the cache file, and do not let the microdescriptor stay recorded as present in its old location. Fixes bug 9047; bugfix on 0.2.2.6-alpha. - Fix a memory leak that would occur whenever a configuration option changed. Fixes bug 8718; bugfix on 0.2.3.3-alpha. - Paste the description for PathBias parameters from the man page into or.h, so the code documents them too. Fixes bug 7982; bugfix on 0.2.3.17-beta and 0.2.4.8-alpha. - Relays now treat a changed IPv6 ORPort as sufficient reason to publish an updated descriptor. Fixes bug 6026; bugfix on 0.2.4.1-alpha. - When launching a resolve request on behalf of an AF_UNIX control socket, omit the address field of the new entry connection, used in subsequent controller events, rather than letting tor_dup_addr() set it to "<unknown address type>". Fixes bug 8639; bugfix on 0.2.4.12-alpha.
o Minor bugfixes (log messages): - Fix a scaling issue in the path bias accounting code that resulted in "Bug:" log messages from either pathbias_scale_close_rates() or pathbias_count_build_success(). This represents a bugfix on a previous bugfix: the original fix attempted in 0.2.4.10-alpha was incomplete. Fixes bug 8235; bugfix on 0.2.4.1-alpha. - Give a less useless error message when the user asks for an IPv4 address on an IPv6-only port, or vice versa. Fixes bug 8846; bugfix on 0.2.4.7-alpha.
o Minor features: - Downgrade "unexpected SENDME" warnings to protocol-warn for 0.2.4.x, to tolerate bug 8093 for now. - Add an "ignoring-advertised-bws" boolean to the flag-threshold lines in directory authority votes to describe whether they have enough measured bandwidths to ignore advertised (relay descriptor) bandwidth claims. Resolves ticket 8711. - Update to the June 5 2013 Maxmind GeoLite Country database.
o Removed documentation: - Remove some of the older contents of doc/ as obsolete; move others to torspec.git. Fixes bug 8965.
o Code simplification and refactoring: - Avoid using character buffers when constructing most directory objects: this approach was unwieldy and error-prone. Instead, build smartlists of strings, and concatenate them when done.
tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
On Sun, 16 Jun 2013 15:18:47 -0700 Mike Perry mikeperry@torproject.org wrote:
Roger Dingledine:
Tor 0.2.4.13-alpha fixes a variety of potential remote crash vulnerabilities, makes socks5 username/password circuit isolation actually actually work (this time for sure!), and cleans up a bunch of other issues in preparation for a release candidate.
As a heads up, a bug was introduced in this release that allows malicious websites to discover a client's Guard nodes in a very short amount of time (on the order an hour), if those Guard nodes upgrade to this release.
So a random clearnet end-destination website can trace the client all the way through Tor network and discover information not about its exit, not about the middle, but even about the entry node? And nodeS, i.e. all of them?* Wow; can you explain in more detail how that works?
* (then a Three Letter Agency (TLA) can obtain lists of connecting clients from all three Guards, and pretty much "triangulate" the actual source IP of that user either to a bulls-eye hit or a very short list of IPs simultaneously on all three.)
Unfortunately, the bug was introduced by fixing another issue that allows Guard nodes to be selectively DoSed with an OOM condition, so Guard node (and Guard+Exit node) operators are kind of in a jam.
One more reason to abandon the Guard system altogether.
tor-relays@lists.torproject.org