Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#2988 closed defect (implemented)

information disclosure: operating system and platform

Reported by: tagnaq Owned by:
Priority: Medium Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-relay
Cc: tagnaq@…, ioerror, linus@…, bastik.public@…, weasel Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

By running a relay you are disclosing your operating system and platform.

examples:

platform Tor 0.2.1.30 on Linux x86_64
platform Tor 0.2.1.29 (!r8e9b25e6c7a2e70c) on Very recent version of Windows [major=6,minor=1]  [workstation] {terminal services, single user}
platform Tor 0.2.1.30 on Linux i686
platform Tor 0.2.1.30 on Very recent version of Windows [major=6,minor=1]  [workstation] {personal} {terminal services, single user}


To minimize info. discl. the version string should not include the operating system and platform by default.

Child Tickets

Change History (38)

comment:1 Changed 8 years ago by arma

Yeah, this one is more controversial. (I suspect this trac entry is a duplicate of several others.)

The trouble is that we actually use this general info for statistics, to get a sense of network growth, to understand if a certain bug is troubling certain subsets of our relays only, etc.

We used to provide much more detail, and we pared it down to just OS and arch. (I believe
Tor 0.2.2.7-alpha and later provide less info about Windows than your example.)

Making it optional reduces the value to us a lot. Might as well just take it out if we are to do that.

I'm not convinced that the information we're revealing is increasing the harm greatly, compared to what you could learn anyway by remote fingerprinting.

The flip side is a) if you can know exactly what the platform and arch is, you can do your exploits with less risk of getting noticed, and remote fingerprinting really isn't perfect, and b) come on, how much value is there really in knowing this stuff.

comment:2 Changed 8 years ago by tagnaq

Cc: tagnaq@… added

Yes I understand your reason for collecting this information
and I acknowledge that most people probably do not mind publishing OS and arch in the version string.

What about including it by default and offer a possibility to opt-out without the need to patch and recompile?

PublishOsVersion 0|1
This setting specifies if your relay descriptor contains your OS version string or not. The Tor Project (and others) use this published information to create statics about network growth and to understand if certain bugs are toubling certain Tor versions only. This information is of little use for an attacker.
(Default: 1)

comment:3 Changed 8 years ago by Sebastian

Any kind of option will lead to a nontrivial amount of relays setting it, which makes the entire idea broken. We should either remove it or (my preference) keep it as it is.

comment:4 Changed 8 years ago by tagnaq

I do not ignore the fact that this is useful information, but my opinion is that a relay operator should be free to decide whether he wants to disclose this information or not.

I think also if there will be something like 'PublishOsVersion' option, most relays will continue to publish this information.

comment:5 in reply to:  4 ; Changed 8 years ago by rransom

Replying to tagnaq:

I do not ignore the fact that this is useful information, but my opinion is that a relay operator should be free to decide whether he wants to disclose this information or not.

I think also if there will be something like 'PublishOsVersion' option, most relays will continue to publish this information.

They are free to make that decision. They have the source code for Tor, they are free to modify their copy of Tor to either not report its version and/or platform or report a false version and/or platform, and they are free to run their modified copy of Tor as a relay on the public Tor network.

But if many relays do not report their version and platform, and a significant number of them later become incompatible with the rest of the Tor network, we will have to drop all relays that do not provide that information from the consensus. That could be bad.

I'm leaving this ticket open for now, because ioerror has also suggested this option, but I think it's a bad idea.

comment:6 in reply to:  5 ; Changed 8 years ago by tagnaq

Replying to rransom:

they are free to modify their copy of Tor to either not report its version and/or platform or report a false version and/or platform, and they are free to run their modified copy of Tor as a relay on the public Tor network.

Sebastian wrote:

Not reporting version is actively harmful, because Tor clients use that to decide what to use a given relay for.

(from #2980)

What is correct?

comment:7 in reply to:  6 Changed 8 years ago by rransom

Replying to tagnaq:

Replying to rransom:

they are free to modify their copy of Tor to either not report its version and/or platform or report a false version and/or platform, and they are free to run their modified copy of Tor as a relay on the public Tor network.

Sebastian wrote:

Not reporting version is actively harmful, because Tor clients use that to decide what to use a given relay for.

(from #2980)

What is correct?

Both statements are correct.

comment:8 Changed 8 years ago by Sebastian

both is correct. Not reporting your version is harmful, but I can't stop you from doing so anyway.

comment:9 in reply to:  8 Changed 8 years ago by tagnaq

Replying to Sebastian:

both is correct. Not reporting your version is harmful, but I can't stop you from doing so anyway.

Starting with what "granularity" will it be harmful?
Is it only used to differentiate 0.2.1.x from 0.2.2.x?

comment:10 Changed 8 years ago by Sebastian

no, it is fully used

comment:12 in reply to:  11 Changed 8 years ago by rransom

Replying to Sebastian:

For example, see https://gitweb.torproject.org/tor.git/blob/6a726d34e175e40cbf86617f9f9c761b52929f96:/src/or/circuitbuild.c#l3692

That's not a valid example -- there, a Tor client is checking the version stored in a state file.

https://gitweb.torproject.org/tor.git/blob/6a726d34e175e40cbf86617f9f9c761b52929f96:/src/or/dirserv.c#l391 is one case where we check relays' published versions.

comment:13 Changed 8 years ago by arma

Replying to Sebastian:

Any kind of option will lead to a nontrivial amount of relays setting it, which makes the entire idea broken. We should either remove it or (my preference) keep it as it is.

If we make it opt-out and a nontrivial number of relays actually opt out, that would convince me that we should turn it off by default. Relay operators are volunteers after all, and we shouldn't make their Tor do something they dislike too much unless we have an excellent reason.

So I could be talked into adding this as an opt-out feature, sure.

(Disabling the reporting of your Tor version should not be easy, though -- we use that as part of the protocol. That said, we might be able to tolerate not publishing the git hash. Though we already run into problems with people running maint-0.2.2 (which reports they're running Tor 0.2.2.19-alpha when actually they're running something much closer to release-0.2.2).)

comment:14 Changed 8 years ago by Sebastian

weasel got super mad when we didn't have a git hash anymore, he was using it to see how many users his packages have I believe. Maybe we are ok with sacrificing that, but we should let him know beforehand.

comment:15 Changed 8 years ago by Sebastian

Also, if we stop putting in the version, we will need to add more flags showing the compatibility with certain protocol features. I think we should do that, because putting in the version is a prohibitor for alternative relay implementations of Tor. Not that there are any currently, but hey. But as soon as we have that info in, relays' versions are again detectable (at least in a certain range of versions) because they will advertise different capabilities. I don't really see a way to solve this.

comment:16 in reply to:  15 Changed 8 years ago by arma

Replying to Sebastian:

But as soon as we have that info in, relays' versions are again detectable (at least in a certain range of versions) because they will advertise different capabilities

The applied security people I talk to make a big deal out of whether the identification is exact or almost exact. The distinction is whether your exploit has zero chance of being noticed (because you target only and exactly the vulnerable versions) or close-to-zero chance of being noticed. So I think they would regard "in a certain range of versions" as a huge improvement.

comment:17 Changed 8 years ago by nickm

Milestone: Tor: unspecified

comment:18 in reply to:  13 Changed 8 years ago by tagnaq

Replying to arma:

If we make it opt-out and a nontrivial number of relays actually opt out, that would convince me that we should turn it off by default. Relay operators are volunteers after all, and we shouldn't make their Tor do something they dislike too much unless we have an excellent reason.

Thank you for these words.

comment:19 Changed 8 years ago by arma

Cc: ioerror added

comment:20 in reply to:  15 Changed 8 years ago by linus

Cc: linus@… added

Replying to Sebastian:

Also, if we stop putting in the version, we will need to add more flags showing the compatibility with certain protocol features. I think we should do that, because putting in the version is a prohibitor for alternative relay implementations of Tor. Not that there are any currently, but hey. But as soon as we have that info in, relays' versions are again detectable (at least in a certain range of versions) because they will advertise different capabilities. I don't really see a way to solve this.

+1 -- capabilities should not be encoded in the version number of a software package.

Regarding detecting relay version based on capabilities, my guess is that capabilities won't change frequently enough for such a detection to be a issue in practice.

comment:21 Changed 8 years ago by mikeperry

The Tor network has been running for how many years now? How many times in the past have we needed this info? It is definitely not zero for some info, but it is zero for others. I found some very interesting results about the circuit failure rates of Windows machines in the past, but Nick has said this is more directly a function of libevent version and polling method on those machines than Windows itself.

I also agree that we should drop info that makes exploits easier. The arch string seems totally irrelevant to me. I don't think we'll ever see a strong correlation between x86 vs x64 and tor performance or reliability properties.. Sure, x64 may do crypto better. But crypto perf is also a function of many other factors, and this arch info aids exploiters, and may not actually always be obvious by remote fingerprinting with nmap if the system is locked down in other respects.

As for using capabilities instead: we occasionally have bad bugs that apply to specific tor minor versions. For example, the bandwidth lying bug of 0.2.2.23-24 is a useful thing to see, and bugs of this sort are something that will *not* be reflected in a capability string, because it is not intentional functionality.

However, I do feel like we want more info in this string, though. It would be very useful to have the libevent version and polling method included, for example. These should be added to the version string, IMO.

It would be interesting to hear Nick's opinion as to if the libevent polling method would be enough to allow us to drop the OS string entirely. Maybe it is.

So, in my ideal world, the version string would be Tor major+minor version + libevent version + method, with no arch, and no git hash. Maybe also OS, depending on what Nick says about libevent capturing this info.

comment:22 in reply to:  21 ; Changed 8 years ago by rransom

Replying to mikeperry:

So, in my ideal world, the version string would be Tor major+minor version + libevent version + method, with no arch, and no git hash. Maybe also OS, depending on what Nick says about libevent capturing this info.

We need the Git hash to identify Tor instances built from maint-* branches.

comment:23 in reply to:  21 Changed 8 years ago by arma

Replying to mikeperry:

However, I do feel like we want more info in this string, though. It would be very useful to have the libevent version and polling method included, for example. These should be added to the version string, IMO.

And by 'the version string', I think Mike means 'the platform string'.

So, in my ideal world, the version string would be Tor major+minor version + libevent version + method, with no arch, and no git hash. Maybe also OS, depending on what Nick says about libevent capturing this info.

Taking arch out sounds plausible on first glance.

I wonder how much redundancy there is between 'libevent method' and 'OS'.

comment:24 in reply to:  22 ; Changed 8 years ago by mikeperry

Replying to rransom:

Replying to mikeperry:

So, in my ideal world, the version string would be Tor major+minor version + libevent version + method, with no arch, and no git hash. Maybe also OS, depending on what Nick says about libevent capturing this info.

We need the Git hash to identify Tor instances built from maint-* branches.

Yeah, but this is annoying for other reasons... What is stopping us from fixing this issue? Is it just a pain to merge down the autoconf updates, for some reason? Sounds like a separate ticket to me, unless there is some real barrier to making maint behave sanely that we're unlikely to ever address.

comment:25 in reply to:  24 ; Changed 8 years ago by arma

Replying to mikeperry:

Replying to rransom:

We need the Git hash to identify Tor instances built from maint-* branches.

I woud argue the word should be 'use' rather than 'need', but yes.

Yeah, but this is annoying for other reasons... What is stopping us from fixing this issue? Is it just a pain to merge down the autoconf updates, for some reason? Sounds like a separate ticket to me, unless there is some real barrier to making maint behave sanely that we're unlikely to ever address.

This issue is one of the main reasons why we have separate maint-0.2.2 and release-0.2.2 branches in the first place. Otherwise every time you mess with configure.in you'll get a conflict when you merge to the next release branch.

That said, perhaps we could do one final version mucking on the maint-0.2.2 branch, e.g. to change it to "0.2.2.19-maint" or the like.

comment:26 in reply to:  25 ; Changed 8 years ago by Sebastian

Replying to arma:

Replying to mikeperry:

Yeah, but this is annoying for other reasons... What is stopping us from fixing this issue? Is it just a pain to merge down the autoconf updates, for some reason? Sounds like a separate ticket to me, unless there is some real barrier to making maint behave sanely that we're unlikely to ever address.

This issue is one of the main reasons why we have separate maint-0.2.2 and release-0.2.2 branches in the first place. Otherwise every time you mess with configure.in you'll get a conflict when you merge to the next release branch.

That said, perhaps we could do one final version mucking on the maint-0.2.2 branch, e.g. to change it to "0.2.2.19-maint" or the like.

Or we could fix it in other ways, like other projects do. That would require us to change our versioning setup somewhat tho so the version number isn't read from a fixed place

comment:27 in reply to:  26 Changed 8 years ago by yaler

In some cases the informations leaked might be seriously problematic. i.e. Revealing a domain controller with OS ver. and service packs.

Tor 0.2.1.30 on Windows Server 2003 Service Pack 2 [domain controller] {enterprise} {terminal services, single user} {terminal services}

Limiting the OS info. to "Windows" or "Linux" will be very appreciated.

comment:28 Changed 8 years ago by bastik

Cc: bastik.public@… added

I asked an IRC and got pointed here. "Failiol" described an attack on Tor by compromising the systems that run the relays.

Whenever it would turn out that a certain OS is vulnerable to un-allowed remote access, which won't be fixed for Vista because the company decides so, an attack could find a vulnerable system that runs an relay.

As arma points out: "(...) fraction of capacity that's vulnerable, not fraction of relays". That's true and important.

Whenever the Torproject collects this information to find out how well the distribution is growing that's fine. It might be only the publishing of this additional information that's not necessary.

As a Tor user I'd like to see to what Tor versions I connect, because I could guess about it's privacy. It's also nice to see what OSs others are using, but does not require to show so much details.

There's on more thing. It's still possible to guess about the "patching state" by looking at the Tor version that are run by those systems. I always like that openness about Tor, that I know which relays I might connect to and what versions of Tor they run. That's truly another ticket, don't really know if that would be problematical.

comment:29 Changed 8 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.2.3.x-final

I'm persuaded that some version of this is a good idea -- at least, giving less OS info is a good idea. (Giving less Tor info isn't going to work, for reasons described above, though we can stop including the git revision, I think)

comment:30 Changed 8 years ago by Sebastian

Cc: weasel added

Adding weasel to the CC because afaik he uses the git hash

comment:31 Changed 8 years ago by weasel

If it's useful to know which relays run a maint release out there, it's probably also useful to know which of those run a patched version. Currently we relay this information in the git hash. Would using a (deb-0.2.3.8-alpha-3) be any better than that?

comment:32 Changed 8 years ago by nickm

I believe so, yes.

comment:33 Changed 7 years ago by cypherpunks

hi, what is the current status?
Will 0.2.3 offer an option to limit the disclosure to the Tor version (no OS and arch included)?
..really looking forward to it.

comment:34 Changed 7 years ago by nickm

Status: newneeds_review

Please review branch 2988_more in my public repository. It cuts down the OS version and machine info, and drops the git-X stuff. To make packagers happy, it has the ability to add a revision value by setting the "TOR_BUILD_TAG" preprocessor variable.

It's always-on, since if it were an option, anybody who's security-conscious enough to set it would probably be exactly the kind of person who wouldn't need it.

Weasel, is that a reasonable approach for you?

comment:35 in reply to:  34 Changed 7 years ago by weasel

Replying to nickm:

Weasel, is that a reasonable approach for you?

Sounds good to me, thanks for asking.

comment:36 Changed 7 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

Okay, merging it into master (with a patch to make it actually build for me on win32)

comment:37 Changed 7 years ago by nickm

Keywords: tor-relay added

comment:38 Changed 7 years ago by nickm

Component: Tor RelayTor
Note: See TracTickets for help on using tickets.