|Summary:||<net-misc/tor-0.2.3.25: Denial of Service Vulnerability (CVE-2012-5573)|
|Product:||Gentoo Security||Reporter:||Agostino Sarubbo <ago>|
|Component:||Vulnerabilities||Assignee:||Gentoo Security <security>|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
Description Agostino Sarubbo 2012-11-26 15:28:28 UTC
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.
Comment 1 Agostino Sarubbo 2012-11-26 18:51:34 UTC
@maintainer, can we stabilize 0.2.3.25 ?
Comment 2 Anthony Basile 2012-11-26 19:57:53 UTC
(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.
Comment 3 Anthony Basile 2012-11-26 20:36:11 UTC
stable on arm ppc ppc64
Comment 4 Agostino Sarubbo 2012-11-26 21:01:26 UTC
Comment 5 Agostino Sarubbo 2012-11-26 21:01:59 UTC
Comment 6 Anthony Basile 2012-11-27 20:31:17 UTC
@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.
Comment 7 Raúl Porcel (RETIRED) 2012-12-16 19:29:34 UTC
Comment 8 Sean Amoss (RETIRED) 2012-12-16 19:38:16 UTC
Thanks, everyone. GLSA vote: yes.
Comment 9 Stefan Behte (RETIRED) 2012-12-16 22:12:14 UTC
Vote: yes. GLSA request filed.
Comment 10 GLSAMaker/CVETool Bot 2013-01-03 11:43:10 UTC
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.
Comment 11 GLSAMaker/CVETool Bot 2013-01-09 00:29:40 UTC
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).