From https://secunia.com/advisories/51329/ : Description A vulnerability has been reported in Tor, which can be exploited by malicious people to cause a DoS (Denial of Service). The vulnerability is caused due to an error when handling SENDME cells and can be exploited to e.g. cause excessive consumption of memory resources within an entry node. Solution Upgrade to version 0.2.3.25.
@maintainer, can we stabilize 0.2.3.25 ?
(In reply to comment #1) > @maintainer, can we stabilize 0.2.3.25 ? I knew this was coming, so I got everything ready. Arch teams target KEYWORDS="~amd64 ~arm ~ppc ~ppc64 ~sparc ~x86" I'll take care of arm, ppc and ppc64 in a minute.
stable on arm ppc ppc64
amd64 stable
x86 stable
@sparc. I had USE=nat-pmp and USE=upnp masked for net-misc/tor across all arches and just unmasked them for amd64 and x86. Testing on arm, mips, ppc and pp64 showed that they now work there so I unmasked them for *all* arches. When stabilizing tor for sparc, please also test net-libs/libnatpmp and net-libs/miniupnpc and either keyword/stabilize or mask those flags.
sparc stable
Thanks, everyone. GLSA vote: yes.
Vote: yes. GLSA request filed.
CVE-2012-5573 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-5573): The connection_edge_process_relay_cell function in or/relay.c in Tor before 0.2.3.25 maintains circuits even if an unexpected SENDME cell arrives, which might allow remote attackers to cause a denial of service (memory consumption or excessive cell reception rate) or bypass intended flow-control restrictions via a RELAY_COMMAND_SENDME command.
This issue was resolved and addressed in GLSA 201301-03 at http://security.gentoo.org/glsa/glsa-201301-03.xml by GLSA coordinator Sean Amoss (ackle).
