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!
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.
Component: RPM Packages => Security
CC: (none) => boklm
ping ?
CC: (none) => cazzaniga.sandroAssignee: bugsquad => boklm
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.
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
Indeed, we are missing a fix for two CVEs in tor in Mageia 1. See: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2768 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2769 https://blog.torproject.org/blog/tor-02234-released-security-patches http://lwn.net/Vulnerabilities/464863/
CC: (none) => luigiwalserSummary: Running an out of date tor is a security risk => tor missing an update for security issues CVE-2011-2768 and CVE-2011-2769
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
Version: 1 => CauldronWhiteboard: (none) => MGA2TOO, MGA1TOO
CC: (none) => fundawang
CC: (none) => dmorganec
Fixed in Cauldron by Sandro.
Version: Cauldron => 2Assignee: boklm => cazzaniga.sandroWhiteboard: MGA2TOO, MGA1TOO => MGA1TOO
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/
Summary: tor missing an update for security issues CVE-2011-2768 and CVE-2011-2769 => tor missing an update for security issues CVE-2011-276[89] and CVE-2012-351[7-9]
CC: (none) => mageia
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/
Summary: tor missing an update for security issues CVE-2011-276[89] and CVE-2012-351[7-9] => tor missing an update for security issues CVE-2011-276[89], CVE-2012-351[7-9], and CVE-2012-4419
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
Can I backport tor-0.2.2.39 from cauldron, so?
Backported in core/updates_testing.
(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,
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.
No subrel in mga2, done.
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.
Should be fixed in cauldron by tor-0.2.2.39-3.mga3. For mageia 1, I think backport need more work.
http://svnweb.mageia.org/packages?view=revision&revision=297449 Does all is done now?
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
Assignee: cazzaniga.sandro => qa-bugs
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
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
Keywords: (none) => validated_updateCC: (none) => davidwhodgins, sysadmin-bugsWhiteboard: MGA1TOO => MGA1TOO MGA2-64-OK MGA2-32-OK MGA1-64-OK MGA1-32-OK
Update pushed: https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0276
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED
The other denial of service fixed in 0.2.2.39 was assigned CVE-2012-4922. http://lwn.net/Vulnerabilities/518322/
CC: boklm => (none)