[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-dev] [tor-announce] Tor 0.2.2.35 is released (security patches)



Should we think to have all tor-users that run a version minor than X,
go automatically off-the-network?

I mean, if we have let's say 10% of outdated users, it means that 10% of
the network can be compromised with a single remote exploit.

I mean, running a Tor node today it's a responsibility.

If a node maintainer it not going to update within a possibly defined
grace period, it should imho get kicked-out from the network.

Has been this concept already considered somehow?
I mean, at least if a node is not updated for example, it would never be
able to achieve a certain "status" or functionalities.
For example never become a Guard node or never became an Exit Node?

-naif

On 12/16/11 7:19 PM, Roger Dingledine wrote:
> Tor 0.2.2.35 fixes a critical heap-overflow security issue in Tor's
> buffers code. Absolutely everybody should upgrade.
> 
> The bug relied on an incorrect calculation when making data continuous
> in one of our IO buffers, if the first chunk of the buffer was
> misaligned by just the wrong amount. The miscalculation would allow an
> attacker to overflow a piece of heap-allocated memory. To mount this
> attack, the attacker would need to either open a SOCKS connection to
> Tor's SocksPort (usually restricted to localhost), or target a Tor
> instance configured to make its connections through a SOCKS proxy
> (which Tor does not do by default).
> 
> Good security practice requires that all heap-overflow bugs should be
> presumed to be exploitable until proven otherwise, so we are treating
> this as a potential code execution attack. Please upgrade immediately!
> This bug does not affect bufferevents-based builds of Tor. Special
> thanks to "Vektor" for reporting this issue to us!
> 
> Tor 0.2.2.35 also fixes several bugs in previous versions, including
> crash bugs for unusual configurations, and a long-term bug that
> would prevent Tor from starting on Windows machines with draconian
> AV software.
> 
> With this release, we remind everyone that 0.2.0.x has reached its
> formal end-of-life. Those Tor versions have many known flaws, and
> nobody should be using them. You should upgrade -- ideally to the
> 0.2.2.x series. If you're using a Linux or BSD and its packages are
> obsolete, stop using those packages and upgrade anyway.
> 
> The Tor 0.2.1.x series is also approaching its end-of-life: it will no
> longer receive support after some time in early 2012.
> 
> https://www.torproject.org/download/download
> 
> Note that the tarball and git tags are signed by Nick Mathewson (gpg
> key 165733EA) this time around.
> 
> Changes in version 0.2.2.35 - 2011-12-16
>   o Major bugfixes:
>     - Fix a heap overflow bug that could occur when trying to pull
>       data into the first chunk of a buffer, when that chunk had
>       already had some data drained from it. Fixes CVE-2011-2778;
>       bugfix on 0.2.0.16-alpha. Reported by "Vektor".
>     - Initialize Libevent with the EVENT_BASE_FLAG_NOLOCK flag enabled, so
>       that it doesn't attempt to allocate a socketpair. This could cause
>       some problems on Windows systems with overzealous firewalls. Fix for
>       bug 4457; workaround for Libevent versions 2.0.1-alpha through
>       2.0.15-stable.
>     - If we mark an OR connection for close based on a cell we process,
>       don't process any further cells on it. We already avoid further
>       reads on marked-for-close connections, but now we also discard the
>       cells we'd already read. Fixes bug 4299; bugfix on 0.2.0.10-alpha,
>       which was the first version where we might mark a connection for
>       close based on processing a cell on it.
>     - Correctly sanity-check that we don't underflow on a memory
>       allocation (and then assert) for hidden service introduction
>       point decryption. Bug discovered by Dan Rosenberg. Fixes bug 4410;
>       bugfix on 0.2.1.5-alpha.
>     - Fix a memory leak when we check whether a hidden service
>       descriptor has any usable introduction points left. Fixes bug
>       4424. Bugfix on 0.2.2.25-alpha.
>     - Don't crash when we're running as a relay and don't have a GeoIP
>       file. Bugfix on 0.2.2.34; fixes bug 4340. This backports a fix
>       we've had in the 0.2.3.x branch already.
>     - When running as a client, do not print a misleading (and plain
>       wrong) log message that we're collecting "directory request"
>       statistics: clients don't collect statistics. Also don't create a
>       useless (because empty) stats file in the stats/ directory. Fixes
>       bug 4353; bugfix on 0.2.2.34.
> 
>   o Minor bugfixes:
>     - Detect failure to initialize Libevent. This fix provides better
>       detection for future instances of bug 4457.
>     - Avoid frequent calls to the fairly expensive cull_wedged_cpuworkers
>       function. This was eating up hideously large amounts of time on some
>       busy servers. Fixes bug 4518; bugfix on 0.0.9.8.
>     - Resolve an integer overflow bug in smartlist_ensure_capacity().
>       Fixes bug 4230; bugfix on Tor 0.1.0.1-rc. Based on a patch by
>       Mansour Moufid.
>     - Don't warn about unused log_mutex in log.c when building with
>       --disable-threads using a recent GCC. Fixes bug 4437; bugfix on
>       0.1.0.6-rc which introduced --disable-threads.
>     - When configuring, starting, or stopping an NT service, stop
>       immediately after the service configuration attempt has succeeded
>       or failed. Fixes bug 3963; bugfix on 0.2.0.7-alpha.
>     - When sending a NETINFO cell, include the original address
>       received for the other side, not its canonical address. Found
>       by "troll_un"; fixes bug 4349; bugfix on 0.2.0.10-alpha.
>     - Fix a typo in a hibernation-related log message. Fixes bug 4331;
>       bugfix on 0.2.2.23-alpha; found by "tmpname0901".
>     - Fix a memory leak in launch_direct_bridge_descriptor_fetch() that
>       occurred when a client tried to fetch a descriptor for a bridge
>       in ExcludeNodes. Fixes bug 4383; bugfix on 0.2.2.25-alpha.
>     - Backport fixes for a pair of compilation warnings on Windows.
>       Fixes bug 4521; bugfix on 0.2.2.28-beta and on 0.2.2.29-beta.
>     - If we had ever tried to call tor_addr_to_str on an address of
>       unknown type, we would have done a strdup on an uninitialized
>       buffer. Now we won't. Fixes bug 4529; bugfix on 0.2.1.3-alpha.
>       Reported by "troll_un".
>     - Correctly detect and handle transient lookup failures from
>       tor_addr_lookup. Fixes bug 4530; bugfix on 0.2.1.5-alpha.
>       Reported by "troll_un".
>     - Fix null-pointer access that could occur if TLS allocation failed.
>       Fixes bug 4531; bugfix on 0.2.0.20-rc. Found by "troll_un".
>     - Use tor_socket_t type for listener argument to accept(). Fixes bug
>       4535; bugfix on 0.2.2.28-beta. Found by "troll_un".
> 
>   o Minor features:
>     - Add two new config options for directory authorities:
>       AuthDirFastGuarantee sets a bandwidth threshold for guaranteeing the
>       Fast flag, and AuthDirGuardBWGuarantee sets a bandwidth threshold
>       that is always sufficient to satisfy the bandwidth requirement for
>       the Guard flag. Now it will be easier for researchers to simulate
>       Tor networks with different values. Resolves ticket 4484.
>     - When Tor ignores a hidden service specified in its configuration,
>       include the hidden service's directory in the warning message.
>       Previously, we would only tell the user that some hidden service
>       was ignored. Bugfix on 0.0.6; fixes bug 4426.
>     - Update to the December 6 2011 Maxmind GeoLite Country database.
> 
>   o Packaging changes:
>     - Make it easier to automate expert package builds on Windows,
>       by removing an absolute path from makensis.exe command.
> 
> 
> 
> 
> _______________________________________________
> tor-announce mailing list
> tor-announce@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-announce

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev