Bug 597394 – <net-misc/tor-0.2.8.9 - multiple vulnerabilities

• Status: RESOLVED FIXED
• Product: Gentoo Security

[Description Anthony Basile 2016-10-17 23:49:07 UTC]

I just added 0.2.8.9 to the tree, but its a security fix, so we need to rapid stabilize it.

[Comment 1 Anthony Basile 2016-10-17 23:52:55 UTC]

@arch teams, please stabilize on the following:

KEYWORDS="amd64 arm ppc ppc64 sparc x86"

[Comment 2 Michael Palimaka (kensington) 2016-10-26 08:01:55 UTC]

amd64/x86 stable

[Comment 3 Jeroen Roovers (RETIRED) 2016-11-04 07:29:05 UTC]

(In reply to Anthony Basile from comment #0)
> its a security fix

[Comment 4 Jeroen Roovers (RETIRED) 2016-11-04 07:30:47 UTC]

Changes in version 0.2.8.9 - 2016-10-17
  Tor 0.2.8.9 backports a fix for a security hole in previous versions
  of Tor that would allow a remote attacker to crash a Tor client,
  hidden service, relay, or authority. All Tor users should upgrade to
  this version, or to 0.2.9.4-alpha. Patches will be released for older
  versions of Tor.

  o Major features (security fixes, also in 0.2.9.4-alpha):
    - Prevent a class of security bugs caused by treating the contents
      of a buffer chunk as if they were a NUL-terminated string. At
      least one such bug seems to be present in all currently used
      versions of Tor, and would allow an attacker to remotely crash
      most Tor instances, especially those compiled with extra compiler
      hardening. With this defense in place, such bugs can't crash Tor,
      though we should still fix them as they occur. Closes ticket
      20384 (TROVE-2016-10-001).

[Comment 5 Michael Palimaka (kensington) 2016-11-04 16:38:25 UTC]

(In reply to Jeroen Roovers from comment #3)
> (In reply to Anthony Basile from comment #0)
> > its a security fix

It's being tracked in bug #597524.

[Comment 6 Anthony Basile 2016-11-04 16:58:24 UTC]

(In reply to Michael Palimaka (kensington) from comment #5)
> (In reply to Jeroen Roovers from comment #3)
> > (In reply to Anthony Basile from comment #0)
> > > its a security fix
> 
> It's being tracked in bug #597524.

I opened this bug before Ago opened #597524.

[Comment 7 Michael Palimaka (kensington) 2016-11-04 17:58:47 UTC]

(In reply to Anthony Basile from comment #6)
> (In reply to Michael Palimaka (kensington) from comment #5)
> > (In reply to Jeroen Roovers from comment #3)
> > > (In reply to Anthony Basile from comment #0)
> > > > its a security fix
> > 
> > It's being tracked in bug #597524.
> 
> I opened this bug before Ago opened #597524.

Yes, but is there any point repurposing this as a security bug when one already exists (even if it was filed later)?

[Comment 8 Jeroen Roovers (RETIRED) 2016-11-05 09:54:35 UTC]

Stable for PPC64.

(In reply to Michael Palimaka (kensington) from comment #7)
> Yes, but is there any point repurposing this as a security bug when one
> already exists (even if it was filed later)?

Yes, because the people doing the stabilisations might want to see that a stabilisation request pertains to a security issue so they can prioritise bugs in their workflows. So it isn't "repurposing" as such, it's just a matter of raising the correct flags. Marking this one as a duplicate of the other, or vice versa, would have been fine as well, as long as architecture teams can see the difference between security and non-security stabilisations.

[Comment 9 Jeroen Roovers (RETIRED) 2016-11-05 09:58:44 UTC]

(In reply to Anthony Basile from comment #6)
> I opened this bug before Ago opened #597524.

Why was this bug report not assigned to Security, then? It just makes no sense.

[Comment 10 Markus Meier 2016-11-10 17:47:26 UTC]

arm stable

[Comment 11 Agostino Sarubbo 2016-12-19 14:38:17 UTC]

sparc stable

[Comment 12 Agostino Sarubbo 2016-12-20 09:48:03 UTC]

ppc stable.

Maintainer(s), please cleanup.

[Comment 13 GLSAMaker/CVETool Bot 2016-12-24 06:51:06 UTC]

This issue was resolved and addressed in
 GLSA 201612-45 at https://security.gentoo.org/glsa/201612-45
by GLSA coordinator Aaron Bauman (b-man).