do not recommend vulnerable tor versions - update "recommended versions"

Most of the tor network runs versions vulnerable to CVE-2016-8860

for a current CW fraction / version distribution see: https://github.com/ornetstats/stats/blob/master/o/version_share.txt

Dir auths still have vulnerable versions in their recommended version string.

Drop all vulnerable version as soon as an updated TBB is available.

added component::core tor/dirauth priority::medium resolution::duplicate severity::normal status::closed type::defect labels

This is problematic, because some Tor binaries with those version numbers will be patched using the patch in #20384 (moved), and some won't be.

current set of recommended versions https://consensus-health.torproject.org/ :

server-versions 0.2.4.26, 0.2.4.27, 0.2.5.11, 0.2.5.12, 0.2.6.5-rc, 0.2.6.6, 0.2.6.7, 0.2.6.8, 0.2.6.9, 0.2.6.10, 0.2.7.1-alpha, 0.2.7.2-alpha, 0.2.7.3-rc, 0.2.7.4-rc, 0.2.7.5, 0.2.7.6, 0.2.8.1-alpha, 0.2.8.2-alpha, 0.2.8.3-alpha, 0.2.8.4-rc, 0.2.8.5-rc, 0.2.8.6, 0.2.8.7, 0.2.8.8, 0.2.8.9, 0.2.9.1-alpha, 0.2.9.2-alpha, 0.2.9.3-alpha, 0.2.9.4-alpha

can be reduced to:

server-versions 0.2.4.27, 0.2.5.12, 0.2.7.6, 0.2.8.9, 0.2.9.4-alpha

backported version: https://security-tracker.debian.org/tracker/CVE-2016-8860

updated: OpenBSD has a backported fix in 0.2.7.6 http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/net/tor/Makefile?rev=1.90.2.1&content-type=text/x-cvsweb-markup&only_with_tag=OPENBSD_6_0

any other backported version we should include?

you might also want to wait until 0.2.8.9 landed in EPEL https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-2f6f1435ed https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-f0f6483aa7

As one of the people responsible for setting this, I feel highly uncomfortable doing it the way we're doing it. Maybe there really SHOULD be a new version if it's just unclear whether currently running versions are vulnerable or not?

Replying to Sebastian:

I feel highly uncomfortable doing it the way we're doing it. Maybe there really SHOULD be a new version if it's just unclear whether currently running versions are vulnerable or not?

I'm not entirely sure I know what you mean by "the way we're doing it", but regarding proper new releases for former branches

https://trac.torproject.org/projects/tor/ticket/20384#comment:4

The patches were released along with new 0.2.8.x and 0.2.9.x releases. I think we probably should have proper releases for everything that we made patches.

If Nick considers https://trac.torproject.org/projects/tor/ticket/20384#comment:4 to be a reasonable request the new versions would probably be:

server-versions 0.2.4.28, 0.2.5.13, 0.2.6.11, 0.2.7.7, 0.2.8.9, 0.2.9.4-alpha

(to be set after packages are available in debian and EPEL repos)

Let's take a step back here:

The last time we removed recommended versions, it was because they simply would not work: they did not believe enough current directory authorities. This seems to me to be a sensible criterion: "will it function?"

What are our general guidelines for setting recommended versions? I suggest that "is it a severe enough bug?" could be another.

Does #20384 (moved) rise to the level that we should stop recommending every version that doesn't have it? It could be, because it affects many clients in some way. But have we done this in the past for bugs of similar severity? I'm not sure.

And, finally, if we do decide we want to eliminate all non-patched versions, should we then increment the minor release version, so we can recommend versions that definitely have this fix? (It may be too late to do this now.)

Replying to teor:

Let's take a step back here:

The last time we removed recommended versions, it was because they simply would not work: they did not believe enough current directory authorities. This seems to me to be a sensible criterion: "will it function?"

What are our general guidelines for setting recommended versions? I suggest that "is it a severe enough bug?" could be another.

I think the latter is more along the lines of what we actually have been doing in the past.

Does #20384 (moved) rise to the level that we should stop recommending every version that doesn't have it? It could be, because it affects many clients in some way. But have we done this in the past for bugs of similar severity? I'm not sure.

It definitely has an anonymity impact due to crashing a significant portion of the network. I'm actually less concerned about clients, because most of those will use Tor Browser which is on a more recent version anyway.

And, finally, if we do decide we want to eliminate all non-patched versions, should we then increment the minor release version, so we can recommend versions that definitely have this fix? (It may be too late to do this now.)

I think we should definitely do that from now on, even if it may be too late to do it this time.

Roger made his opinion clear ;) https://lists.torproject.org/pipermail/tor-consensus-health/2016-October/007486.html

Now it takes just one more dirauth to flip and the parameters will change in the consensus.

Note: updated packages did not reach EPEL yet.

I'm surprised you even removed the latest shipped tor in current TBB (there is no TBB with tor v0.2.8.9 yet) but so be it.

New consensus is:

consensus 	
        client-versions 0.2.5.12, 0.2.7.6, 0.2.8.9, 0.2.9.4-alpha
	server-versions 0.2.5.12, 0.2.7.6, 0.2.8.9, 0.2.9.4-alpha

Every TBB user will get a warning in now?

This ticket is implemented.

Trac:
Status: new to closed
Resolution: N/A to implemented

Hrm I see that we've reached consensus on those but this hasn't been pushed to dirauth-conf git repository. Can a dirauth do that?

Trac:
Resolution: implemented to N/A
Status: closed to reopened

Is that done even if dir auths disagree? (which is the case here) https://consensus-health.torproject.org/#recommendedversions

#21327 (moved)

Trac:
Resolution: N/A to duplicate
Status: reopened to closed

closed

moved to tpo/core/dirauth#20431 (closed)