| Summary: | <net-misc/tor-0.2.8.9 - multiple vulnerabilities | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Anthony Basile <blueness> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | blueness, kensington, luke, ncl |
| Priority: | Normal | Flags: | kensington:
sanity-check+
|
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://gitweb.torproject.org/tor.git/tree/ChangeLog | ||
| Whiteboard: | B3 [glsa] | ||
| Package list: |
net-misc/tor-0.2.8.9
|
Runtime testing required: | --- |
| Bug Depends on: | |||
| Bug Blocks: | 597524 | ||
|
Description
Anthony Basile
2016-10-17 23:49:07 UTC
@arch teams, please stabilize on the following: KEYWORDS="amd64 arm ppc ppc64 sparc x86" amd64/x86 stable (In reply to Anthony Basile from comment #0) > its a security fix 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).
(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. (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. (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)? 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. (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. arm stable sparc stable ppc stable. Maintainer(s), please cleanup. 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). |