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 <simon.dez...@gmail.com> Tue, 15 Aug 2017 02:57:56
+0000
** Changed in: tor (Ubuntu Zesty)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1710753
Title:
Please upgrade Xenial/Zesty to use the latest LTS point release of Tor
(0.2.9)
Status in tor package in Ubuntu:
Fix Released
Status in tor source package in Xenial:
Triaged
Status in tor source package in Zesty:
Fix Released
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
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tor/+bug/1710753/+subscriptions
_______________________________________________
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
