Bug 444804 (CVE-2012-5573) – <net-misc/tor-0.2.3.25: Denial of Service Vulnerability (CVE-2012-5573)

• Product: Gentoo Security
• Status: RESOLVED FIXED

[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]

amd64 stable

[Comment 5 Agostino Sarubbo 2012-11-26 21:01:59 UTC]

x86 stable

[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]

sparc stable

[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).