Bug 5351 - tor missing an update for security issues CVE-2011-276[89], CVE-2012-351[7-9], and CVE-2012-4419
: tor missing an update for security issues CVE-2011-276[89], CVE-2012-351[7-9]...
Status: RESOLVED FIXED
Product: Mageia
Classification: Unclassified
Component: Security
: 2
: All Linux
: Normal Severity: normal
: ---
Assigned To: QA Team
:
:
: MGA1TOO MGA2-64-OK MGA2-32-OK MGA1-64...
: validated_update
:
:
  Show dependency treegraph
 
Reported: 2012-04-11 14:41 CEST by Jim Darby
Modified: 2014-05-08 18:06 CEST (History)
8 users (show)

See Also:
Source RPM: tor-0.2.1.30-1.1.mga1
CVE:


Attachments

Description Jim Darby 2012-04-11 14:41:39 CEST
Description of problem:

Mageia 1 has an out of date version of tor (2.1.30)

Version-Release number of selected component (if applicable):

2.1.30

How reproducible:

Always

Steps to Reproduce:
1. Install tor
2. Start tor
3. Observe it say: "Please upgrade! This version of Tor (0.2.1.30) is obsolete, according to the directory authorities. Recommended versions are: 0.2.1.32,0.2.2.35,0.2.3.10-alpha,0.2.3.11-alpha,0.2.3.12-alpha,0.2.3.13-alpha"

My guess is that either 2.2.35 or perhaps 2.1.32 is the way to go. Having an old, insecure version is not a good idea!
Comment 1 Jim Darby 2012-04-11 14:46:58 CEST
More details on the changes from 0.2.1.30 to 0.2.1.32 can be found at: https://gitweb.torproject.org/tor.git?a=blob_plain;hb=release-0.2.1;f=ReleaseNotes

Although with 0.2.1 going into end-of-life we really ought to be using the 0.2.2 series.
Comment 2 Manuel Hiebel 2012-05-09 21:16:38 CEST
ping ?
Comment 3 Jim Darby 2012-05-10 00:15:06 CEST
I'm still here. I'm currently running a custom built version of tor.

For reference, Mageia 2 beta 3 uses 2.2.35 which is fine.
Comment 4 Marja van Waes 2012-07-06 15:05:57 CEST
Please look at the bottom of this mail to see whether you're the assignee of this  bug, if you don't already know whether you are.


If you're the assignee:

We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead.

If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard.

Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why.

Thanks :)

**************************** 

@ the reporter and persons in the cc of this bug:

If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us.

@ the reporter of this bug

If you didn't reply yet to a request for more information, please do so within two weeks from now.

Thanks all :-D
Comment 6 David Walser 2012-08-20 02:41:28 CEST
Tor 0.2.2.38 is out, and according to the release announcement on freecode.com, it contains a security fix.

http://freecode.com/projects/tor/releases/347460
Comment 7 David Walser 2012-08-29 13:35:21 CEST
Fixed in Cauldron by Sandro.
Comment 8 David Walser 2012-08-30 23:10:41 CEST
OpenSuSE has issued an advisory today (August 30):
http://lists.opensuse.org/opensuse-updates/2012-08/msg00048.html

It identifies the following CVEs as fixed in 0.2.2.38:
CVE-2012-3517 CVE-2012-3518 CVE-2012-3519

from http://lwn.net/Vulnerabilities/514378/
Comment 9 David Walser 2012-09-14 21:32:06 CEST
Debian has issued an advisory on September 13:
http://www.debian.org/security/2012/dsa-2548

It adds the following CVE and a couple DoS issues, probably fixed in 0.2.2.39:
CVE-2012-4419

from http://lwn.net/Vulnerabilities/516323/
Comment 10 David Walser 2012-09-18 02:47:04 CEST
The two DoS are indeed fixed in 0.2.2.39:
http://freecode.com/projects/tor/releases/348256
https://blog.torproject.org/blog/new-bundles-security-release
Comment 11 Sandro Cazzaniga 2012-09-21 07:40:51 CEST
Can I backport tor-0.2.2.39 from cauldron, so?
Comment 12 Sandro Cazzaniga 2012-09-21 08:20:53 CEST
Backported in core/updates_testing.
Comment 13 David Walser 2012-09-21 14:14:28 CEST
(In reply to comment #12)
> Backported in core/updates_testing.

Thanks, yes that does seem to be the best solution.

This is needed for Mageia 1 also,
Comment 14 David Walser 2012-09-21 14:15:40 CEST
Another thing to watch out for, the package you pushed to Mageia 2 updates_testing has a subrel (it shouldn't) which makes it newer than Cauldron.
Comment 15 Sandro Cazzaniga 2012-09-22 06:59:01 CEST
No subrel in mga2, done.
Comment 16 David Walser 2012-09-22 15:27:32 CEST
It's still newer than Cauldron, because the release tag is now 2.  There are 2 ways to fix this:
- ask a sysadmin to remove it from updates_testing, change the release tag back to 1 and resubmit
- rebuild it in Cauldron

Also, a backport to Mageia 1 is still needed as well.
Comment 17 Sandro Cazzaniga 2012-09-24 07:45:47 CEST
Should be fixed in cauldron by tor-0.2.2.39-3.mga3. 

For mageia 1, I think backport need more work.
Comment 18 Sandro Cazzaniga 2012-09-25 08:34:50 CEST
http://svnweb.mageia.org/packages?view=revision&revision=297449

Does all is done now?
Comment 19 David Walser 2012-09-25 15:12:34 CEST
Thanks Sandro!  Now all we need is an advisory, but this can begin testing now.

tor-0.2.2.39-1.mga1
tor-0.2.2.39-2.mga2
Comment 20 David Walser 2012-09-25 21:01:11 CEST
Advisory:
========================

Updated tor package fixes security vulnerabilities:

Tor before 0.2.2.34, when configured as a client or bridge, sends a TLS
certificate chain as part of an outgoing OR connection, which allows
remote relays to bypass intended anonymity properties by reading this
chain and then determining the set of entry guards that the client or
bridge had selected (CVE-2011-2768).

Tor before 0.2.2.34, when configured as a bridge, accepts the CREATE and
CREATE_FAST values in the Command field of a cell within an OR connection
that it initiated, which allows remote relays to enumerate bridges by
using these values (CVE-2011-2769).

Use-after-free vulnerability in dns.c in Tor before 0.2.2.38 might allow
remote attackers to cause a denial of service (daemon crash) via vectors
related to failed DNS requests (CVE-2012-3517).

The networkstatus_parse_vote_from_string function in routerparse.c in Tor
before 0.2.2.38 does not properly handle an invalid flavor name, which
allows remote attackers to cause a denial of service (out-of-bounds read
and daemon crash) via a crafted (1) vote document or (2) consensus
document (CVE-2012-3518).

routerlist.c in Tor before 0.2.2.38 uses a different amount of time for
relay-list iteration depending on which relay is chosen, which might
allow remote attackers to obtain sensitive information about relay
selection via a timing side-channel attack (CVE-2012-3519).

The compare_tor_addr_to_addr_policy function in or/policies.c in Tor
before 0.2.2.39, and 0.2.3.x before 0.2.3.21-rc, allows remote attackers
to cause a denial of service (assertion failure and daemon exit) via a
zero-valued port field that is not properly handled during policy
comparison (CVE-2012-4419).

Tor before 0.2.2.39, when waiting for a client to renegotiate, allowed it
to add bytes to the input buffer, allowing a crash to be caused remotely
(tor-5934, tor-6007).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2768
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2769
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3517
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3518
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3519
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4419
https://blog.torproject.org/blog/tor-02234-released-security-patches
https://trac.torproject.org/projects/tor/ticket/5934
https://trac.torproject.org/projects/tor/ticket/6007
https://blog.torproject.org/blog/new-bundles-security-release
http://www.debian.org/security/2011/dsa-2331
http://lists.opensuse.org/opensuse-updates/2012-08/msg00048.html
http://www.debian.org/security/2012/dsa-2548
========================

Updated packages in core/updates_testing:
========================
tor-0.2.2.39-1.mga1
tor-0.2.2.39-2.mga2

from SRPMS:
tor-0.2.2.39-1.mga1.src.rpm
tor-0.2.2.39-2.mga2.src.rpm
Comment 21 Dave Hodgins 2012-09-25 23:24:04 CEST
Testing complete Mageia 1 and 2, i586 and x86-64.

Testing using opera, with the socks5 proxy set to 127.0.0.1:9050,
and http://whatismyipaddress.com/

Could someone from the sysadmin team push the srpm
tor-0.2.2.39-2.mga2.src.rpm
from Mageia 2 Core Updates Testing to Core Updates and the srpm
tor-0.2.2.39-1.mga1.src.rpm
from Mageia 1 Core Updates Testing to Core Updates.

Advisory: Updated tor package fixes security vulnerabilities:

Tor before 0.2.2.34, when configured as a client or bridge, sends a TLS
certificate chain as part of an outgoing OR connection, which allows
remote relays to bypass intended anonymity properties by reading this
chain and then determining the set of entry guards that the client or
bridge had selected (CVE-2011-2768).

Tor before 0.2.2.34, when configured as a bridge, accepts the CREATE and
CREATE_FAST values in the Command field of a cell within an OR connection
that it initiated, which allows remote relays to enumerate bridges by
using these values (CVE-2011-2769).

Use-after-free vulnerability in dns.c in Tor before 0.2.2.38 might allow
remote attackers to cause a denial of service (daemon crash) via vectors
related to failed DNS requests (CVE-2012-3517).

The networkstatus_parse_vote_from_string function in routerparse.c in Tor
before 0.2.2.38 does not properly handle an invalid flavor name, which
allows remote attackers to cause a denial of service (out-of-bounds read
and daemon crash) via a crafted (1) vote document or (2) consensus
document (CVE-2012-3518).

routerlist.c in Tor before 0.2.2.38 uses a different amount of time for
relay-list iteration depending on which relay is chosen, which might
allow remote attackers to obtain sensitive information about relay
selection via a timing side-channel attack (CVE-2012-3519).

The compare_tor_addr_to_addr_policy function in or/policies.c in Tor
before 0.2.2.39, and 0.2.3.x before 0.2.3.21-rc, allows remote attackers
to cause a denial of service (assertion failure and daemon exit) via a
zero-valued port field that is not properly handled during policy
comparison (CVE-2012-4419).

Tor before 0.2.2.39, when waiting for a client to renegotiate, allowed it
to add bytes to the input buffer, allowing a crash to be caused remotely
(tor-5934, tor-6007).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2768
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2769
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3517
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3518
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3519
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4419
https://blog.torproject.org/blog/tor-02234-released-security-patches
https://trac.torproject.org/projects/tor/ticket/5934
https://trac.torproject.org/projects/tor/ticket/6007
https://blog.torproject.org/blog/new-bundles-security-release
http://www.debian.org/security/2011/dsa-2331
http://lists.opensuse.org/opensuse-updates/2012-08/msg00048.html
http://www.debian.org/security/2012/dsa-2548

https://bugs.mageia.org/show_bug.cgi?id=5351
Comment 22 Thomas Backlund 2012-09-30 20:55:16 CEST
Update pushed:
https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0276
Comment 23 David Walser 2012-10-02 21:15:09 CEST
The other denial of service fixed in 0.2.2.39 was assigned CVE-2012-4922.

http://lwn.net/Vulnerabilities/518322/

Note You need to log in before you can comment on or make changes to this bug.