Please upgrade Xenial/Zesty to use the latest LTS point release of Tor (0.2.9)

Bug #1710753 reported by Simon Déziel on 2017-08-15
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
tor (Ubuntu)
Undecided
Unassigned
Xenial
Medium
Simon Déziel
Zesty
Medium
Simon Déziel

Bug Description

[Impact]

Currently, Zesty ships with Tor 0.2.9.10 but the latest point release is 0.2.9.11 [1]. Xenial is shipping 0.2.7.6 while the 0.2.7 branch reached its end of life on August 1st 2017 [2].
Since Tor is a security sensitive package, tracking upstream point releases for that LTS branch would keep Ubuntu users safe.

[1] https://gitweb.torproject.org/tor.git/plain/ReleaseNotes?id=tor-0.2.9.11
[2] https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases

[Test Case]

1) Setup Tor:
$ sudo apt-get install tor

2) Check that you can use the Tor network:
$ torsocks wget -qO - ifconfig.me/ip
192.0.2.1

3) Check that the IP returned by ifconfig.me/ip is NOT the one
   that is assigned by you ISP.
4) If you got a different IP it means your wget used the Tor network successfully
5) Repeat with the -proposed package

[Regression Potential]

Regression risk should be low since it's a backport from Debian Stretch that was released in June 2017.
On top of that, 2 changes were cherry picked from 0.3.0.10-1 and 0.3.0.4-rc-1 to use DAC_READ_SEARCH
instead of DAC_OVERRIDE in the Apparmor profile and the systemd units. The full DAC_OVERRIDE capability
turned out to be unnecessary.

If the capability change turns out to cause problem, Tor should either stop functionning (refuse to initialize)
or be unable to offer some features (like hidden services). Such regression should be visible through Apparmor
denial logs. Since it's a privilege reduction change, the user's security shouldn't be compromised.

[Other Info]

It's also easy to test the hidden service feature using the local SSH daemon. Here's how to do so:

1) Expose your SSH daemon via hidden service:
$ cat << EOF >> /etc/tor/torrc
HiddenServiceDir /var/lib/tor/hidden_service_sshd/
HiddenServicePort 22 127.0.0.1:22
EOF

2) Restart Tor:
$ sudo service tor restart

3) Connect to your local hidden service by looping through the Tor network:
$ torsocks nc $(cat /var/lib/tor/hidden_service_sshd/hostname) 22 <<< quit
SSH-2.0-OpenSSH_7.4p1
Protocol mismatch.

4) The above version string and protocol mismatch are proof that you were able to connect through Tor.
   You can further prove that by checking your ssh logs:
$ journalctl -o cat -u ssh | tail -n1
Bad protocol version identification 'quit' from 127.0.0.1 port 39960

Simon Déziel (sdeziel) wrote :

Here is Zesty's debdiff

Simon Déziel (sdeziel) wrote :

And here is Xenial's debdiff

The attachment "lp1710753-17.10.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

tags: added: patch
David Goulet (dgoulet) wrote :

Greetings!

(Tor developer here)

As stated above, the 0.2.7.x series is now EOL since August 1st, 2017 meaning that we will NOT fix any bugs nor do any new releases even in the event of a catastrophic security issue.

Unfortunately, Tor does see security issues from time to time and the rate could increase that now our Bug Bounty program has gone public[1]. We've started to document each of them thoroughly on our wiki[2] so keeping anything EOL in Ubuntu for something as sensitive as Tor is really not ideal and potentially puts our users and network at risk.

So we (Tor upstream), strongly recommend that any unmaintained version should be dropped from Ubuntu, at the very least for security purposes, and the Tor LTS[3] series should be used for Ubuntu's LTS. The 0.2.9.x series is the latest LTS which is also the one in Debian Stretch for which we'll be supporting until Jan 1st, 2020.

I believe sdeziel also has volunteered to properly maintain the health of the "tor" package in Ubuntu and our Debian packager (weasel) has been doing a fantastic job at keeping tor packages stable, up to date and released in time for any security issues we've had.

Please, feel free to reach out if you have any questions or concerns.
Thanks!

[1] https://hackerone.com/torproject
[2] https://trac.torproject.org/projects/tor/wiki/TROVE
[3] https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in tor (Ubuntu):
status: New → Confirmed
Changed in tor (Ubuntu):
status: Confirmed → Fix Released
Changed in tor (Ubuntu Xenial):
status: New → Triaged
Changed in tor (Ubuntu Zesty):
status: New → Triaged
Changed in tor (Ubuntu Xenial):
importance: Undecided → Medium
Changed in tor (Ubuntu Zesty):
importance: Undecided → Medium
Changed in tor (Ubuntu Xenial):
assignee: nobody → Simon Déziel (sdeziel)
Changed in tor (Ubuntu Zesty):
assignee: nobody → Simon Déziel (sdeziel)
Stéphane Graber (stgraber) wrote :

Hi,

I agree that even though "tor" is in universe, it's very important for its users that it is functional and safe. I had a chat with Tor upstream about this and the recommendation was effectively to either use their LTS releases and keep up with their security updates, which Simon kindly offered to do for us, or remove the package from the archive entirely, forcing tor users to go and get it from upstream directly.

Since Simon volunteered to do the Ubuntu maintenance for Tor, I'm fine with both updating zesty to the latest bugfix release of that LTS series (and that would already fit the normal SRU process). But I'm also happy with bumping the tor release in xenial to be something which upstream offers LTS support on.

To minimize the risk of regressions, we'll do that in a few step:
 1) I'm going to accept the zesty SRU into -proposed
 2) We'll wait for it to be verified and released to -updates
 3) We'll then let the xenial SRU into -proposed (effectively same content as the zesty one)
 4) We'll wait for it to be verified and if no bug was filed against either the xenial or zesty SRU by that point, will release it too

This effectively doubles the testing time for the package, slowly exposing it to more and more users:
 - First to zesty-proposed users
 - Then to zesty-updates users too
 - And then to those as well as xenial-proposed users

That will likely take us 2-3 weeks to get it all done at which point we'll have a supportable tor in both xenial and zesty.

Hello Simon, or anyone else affected,

Accepted tor into zesty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/tor/0.2.9.11-1ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-zesty to verification-done-zesty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-zesty. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in tor (Ubuntu Zesty):
status: Triaged → Fix Committed
tags: added: verification-needed verification-needed-zesty
Stéphane Graber (stgraber) wrote :

Accepted the zesty SRU. Please install it, test it and document how it's been tested in this bug report. We'll want to make sure we do the exact same testing for the Xenial SRU later.

Simon Déziel (sdeziel) on 2017-08-25
description: updated
Simon Déziel (sdeziel) wrote :

Verified on Zesty with the SRU test case (wget and SSH hidden service)

$ sudo apt-get dist-upgrade -V
...
The following packages will be upgraded:
   tor (0.2.9.10-1ubuntu1 => 0.2.9.11-1ubuntu1)
   tor-geoipdb (0.2.9.10-1ubuntu1 => 0.2.9.11-1ubuntu1)

tags: added: verification-done-zesty
removed: verification-needed-zesty
Peter Palfrader (weasel) wrote :

> + On top of that, 2 changes were cherry picked from 0.3.0.10-1 and 0.3.0.4-rc-1 to use DAC_READ_SEARCH

If you're cherry picking, you might also want to consider the changes committed to git that switch
the apparmor profile to use Pix instead of PUx, and maybe the sysV init script fix.

cf. https://gitweb.torproject.org/debian/tor.git/tree/debian/changelog

Cheers

Simon Déziel (sdeziel) wrote :

Thanks Peter, I appreciate it! Since the package is already in zesty-proposed I'll keep those cherry picks for the next version. I'm surprised that obfs{,4}proxy don't use a dedicated profile. I'll get familiar with those an maybe get in touch with your for more Apparmor stuff :)

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package tor - 0.2.9.11-1ubuntu1

---------------
tor (0.2.9.11-1ubuntu1) zesty; urgency=medium

  * Backport from Debian Stretch to Zesty. Ubuntu Delta: (LP: #1710753)
    - Limit the seccomp build-dependency to [amd64 i386 armhf].
    - Drop build-conflicts.
    - Update debian/micro-revision.i to match 0.2.9.11 commit ID.
    - Use DAC_READ_SEARCH instead of DAC_OVERRIDE for Apparmor and
      systemd units. Cherry picked from 0.3.0.10-1 and 0.3.0.4-rc-1.

 -- Simon Deziel <email address hidden> Tue, 15 Aug 2017 02:57:56 +0000

Changed in tor (Ubuntu Zesty):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for tor has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Hello Simon, or anyone else affected,

Accepted tor into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/tor/0.2.9.11-1ubuntu1~16.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in tor (Ubuntu Xenial):
status: Triaged → Fix Committed
tags: added: verification-needed-xenial
Simon Déziel (sdeziel) wrote :

Verified on Xenial with the SRU test case (wget and SSH hidden service).

$ sudo apt-get dist-upgrade -V
...
The following packages will be upgraded:
   tor (0.2.7.6-1ubuntu1 => 0.2.9.11-1ubuntu1~16.04.1)
   tor-geoipdb (0.2.7.6-1ubuntu1 => 0.2.9.11-1ubuntu1~16.04.1)

tags: added: verification-done verification-done-xenial
removed: verification-needed verification-needed-xenial
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package tor - 0.2.9.11-1ubuntu1~16.04.1

---------------
tor (0.2.9.11-1ubuntu1~16.04.1) xenial; urgency=medium

  * Backport from Debian Stretch to Xenial. Ubuntu Delta: (LP: #1710753)
    - Limit the seccomp build-dependency to [amd64 i386 armhf].
    - Drop build-conflicts.
    - Update debian/micro-revision.i to match 0.2.9.11 commit ID.
    - Use DAC_READ_SEARCH instead of DAC_OVERRIDE for Apparmor and
      systemd units. Cherry picked from 0.3.0.10-1 and 0.3.0.4-rc-1.
    - Limit the seccomp build-dependency to [amd64 i386 x32 armel armhf].

 -- Simon Deziel <email address hidden> Tue, 15 Aug 2017 02:57:56 +0000

Changed in tor (Ubuntu Xenial):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers