From $URL: Tor 0.2.3.10-alpha 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! This release also contains a few minor bugfixes for issues discovered in 0.2.3.9-alpha. 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.3.10-alpha - 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". o Minor bugfixes: - If we can't attach streams to a rendezvous circuit when we finish connecting to a hidden service, clear the rendezvous circuit's stream-isolation state and try to attach streams again. Previously, we cleared rendezvous circuits' isolation state either too early (if they were freshly built) or not at all (if they had been built earlier and were cannibalized). Bugfix on 0.2.3.3-alpha; fixes bug 4655. - Fix compilation of the libnatpmp helper on non-Windows. Bugfix on 0.2.3.9-alpha; fixes bug 4691. Reported by Anthony G. Basile. - Fix an assertion failure when a relay with accounting enabled starts up while dormant. Fixes bug 4702; bugfix on 0.2.3.9-alpha. o Minor features: - Update to the December 6 2011 Maxmind GeoLite Country database.
I added tor-0.2.1.32 tor-0.2.2.35 and tor-0.2.3.10_alpha to the tree.
(In reply to comment #1) > I added tor-0.2.1.32 tor-0.2.2.35 and tor-0.2.3.10_alpha to the tree. Thanks, Anthony. Is tor-0.2.2.35 the stabilization target?
Tim yes, we need a rapid stabilizaton of tor-0.2.2.35.ebuild. (We actually had a mid air collision just as I was adding the arch teams.) The heap overflow doesn't just effect 0.2.3.9, it also effect 0.2.2.34 and 0.2.1.31. See the ChangleLog for 0.2.2.35: https://gitweb.torproject.org/tor.git/blobdiff/796563f7f3924fb5f2bed39cd37e1471da657cc4..b04388f9e7546a9f0c77f0d72e41fefb4106d2b5:/ReleaseNotes
(In reply to comment #3) > Tim yes, we need a rapid stabilizaton of tor-0.2.2.35.ebuild. > Indeed, thank you. Arches, please test and mark stable: =net-misc/tor-0.2.2.35 Target keywords : "amd64 arm ppc ppc64 sparc x86"
amd64: pass
@blueness and other tester(s) I found bug 395039 bug 395041 bug 395043 because net-libs/libnatpmp is a depend but only the first is a blocker because I can't merge it.
(In reply to comment #6) > @blueness and other tester(s) > > I found bug 395039 bug 395041 bug 395043 because net-libs/libnatpmp is a depend > but only the first is a blocker because I can't merge it. libnatpmp is only used by the alpha branch which is not being stabilized. blueness@yellowness /usr/portage/net-misc/tor $ grep libnatpmp * tor-0.2.3.10_alpha.ebuild: nat-pmp? ( net-libs/libnatpmp ) @arch testers please continue stabilization of tor-0.2.2.35
(In reply to comment #7) > libnatpmp is only used by the alpha branch which is not being stabilized. Sorry, my bad, I merged a bad version.
amd64/x86 stable
arm stable
ppc/ppc64 done
(In reply to comment #11) > ppc/ppc64 done Please do not break the portage tree! * Digest verification failed: * /usr/portage/net-misc/tor/tor-0.2.2.35.ebuild * Reason: Filesize does not match recorded size * Got: 2085 * Expected: 2086 -- this will be in latest portage snapshot for 24h.
(In reply to comment #12) > (In reply to comment #11) > > ppc/ppc64 done > > Please do not break the portage tree! > > * Digest verification failed: > * /usr/portage/net-misc/tor/tor-0.2.2.35.ebuild > * Reason: Filesize does not match recorded size > * Got: 2085 > * Expected: 2086 > > -- this will be in latest portage snapshot for 24h. I'm not seeing this, how did you hit it?
sparc stable
Thanks, everyone. GLSA request filed.
> I'm not seeing this, how did you hit it? I saw it in emerge-webrsync. I assumed that it uses the regular portage snapshots. (Sorry for offtopic.)
This issue was resolved and addressed in GLSA 201201-12 at http://security.gentoo.org/glsa/glsa-201201-12.xml by GLSA coordinator Sean Amoss (ackle).
CVE-2011-2778 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-2778): Multiple heap-based buffer overflows in Tor before 0.2.2.35 allow remote attackers to cause a denial of service (memory corruption) or possibly execute arbitrary code by (1) establishing a SOCKS connection to SocksPort or (2) leveraging a SOCKS proxy configuration.
