Opened 5 years ago

Closed 3 years ago

#5926 closed defect (duplicate)

language info leaked by JS Date methods in Windows and Linux

Reported by: mikeperry Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Keywords: tbb-fingerprinting-locale, interview, tbb-firefox-patch
Cc: gk, arthuredelstein Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

In greg's test at http://pseudo-flaw.net/tor/torbutton/browserfeedwriter-error.html, the Date string ends up localized to the user's language.

We should scrub it or remove it most likely. See also #5922 for info on the relevant source code paths.

Child Tickets

Change History (22)

comment:1 Changed 5 years ago by gk

Cc: g.koppen@… added

comment:2 Changed 5 years ago by mikeperry

Keywords: MikePerry201206 added

comment:3 Changed 5 years ago by mikeperry

Keywords: MikePerry201206 removed

comment:4 Changed 5 years ago by mikeperry

Some additional stuff was exposed on this object in https://bugzilla.mozilla.org/show_bug.cgi?id=743843.

comment:5 Changed 5 years ago by mikeperry

Keywords: interview added

comment:6 Changed 3 years ago by arthuredelstein

Greg's test, mentioned above, produces the Date string not from an nsXPCException (as the ticket title claims), but from a line in the function log(txt) in the source file http://pseudo-flaw.net/tor/torbutton/torbutton-common.js, that contains the expression (new Date()).toLocaleString().

In any case, I have examined the Date string produced by this test under both US English and German versions of TBB, and also under computer locale and language set to both US English and German. In all cases, I see the same Date formatting:
Date: Fri May 9 23:03:18 2014
which corresponds to the current UTC time.

So I think this bug no longer exists, and I would suggest that it can be closed.

comment:7 Changed 3 years ago by gk

Cc: gk added; g.koppen@… removed

I tested it under a german *OS* which gives me something like:

Date: Montag, 12. Mai 2014 09:36:21

So, it seems the bug is not about revealing non-en(-US) TBB locales but about revealing non-en(-US) OS locales. And it is still there in the 3.6.1 series.

comment:8 in reply to:  7 ; Changed 3 years ago by arthuredelstein

Replying to gk:

I tested it under a german *OS* which gives me something like:

Date: Montag, 12. Mai 2014 09:36:21

So, it seems the bug is not about revealing non-en(-US) TBB locales but about revealing non-en(-US) OS locales. And it is still there in the 3.6.1 series.

Interesting. What OS did you test with?

comment:9 Changed 3 years ago by arthuredelstein

OK, I can reproduce this on Ubuntu 14.04 LTS. In the web console, I can also generate localized strings with
English-US:
new Date().toLocaleString(); -> "Mon May 12 18:01:49 2014"
new Date().toLocaleDateString(); -> "05/12/2014"
vs German:
new Date().toLocaleString(); -> "Mo 12 Mai 2014 18:04:56 UTC"
new Date().toLocaleDateString(); -> "12.05.2014"

I'm not able to reproduce this on OS X.

comment:10 in reply to:  8 Changed 3 years ago by gk

Replying to arthuredelstein:

Replying to gk:

I tested it under a german *OS* which gives me something like:

Date: Montag, 12. Mai 2014 09:36:21

So, it seems the bug is not about revealing non-en(-US) TBB locales but about revealing non-en(-US) OS locales. And it is still there in the 3.6.1 series.

Interesting. What OS did you test with?

Windows 7. Seems my test Mac (10.6.8) is not affected by this problem either.

comment:11 Changed 3 years ago by arthuredelstein

Here's a more extensive demo of the Date locale problem. http://jsbin.com/luririxo/1/watch?js,output

comment:12 Changed 3 years ago by arthuredelstein

Summary: nsXPCException leaks language info via Date string in exceptionslanguage info leaked by JS Date methods in Windows and Linux

comment:13 Changed 3 years ago by arthuredelstein

I'm working on a patch for this. Question: Does it make sense to add a preference to turn on and off Date locale anonymization? Or is there another existing pref I should use? If we need a new pref, should it be called something like privacy.javascript.anonymize?

comment:14 Changed 3 years ago by erinn

Keywords: tbb-firefox-patch added

comment:15 Changed 3 years ago by erinn

Component: Firefox Patch IssuesTor Browser
Owner: changed from mikeperry to tbb-team

comment:16 Changed 3 years ago by gk

#13050 is a duplicate of this one.

comment:17 Changed 3 years ago by mikeperry

See also #13019. As for prefs, we currently have extensions.torbutton.spoof_english, spoof_locale and spoof_language, but yes, we probably also want a native browser pref here. Something that clearly indicates this is for locale normalization/spoofing rather than just generic anonymization.

comment:18 Changed 3 years ago by mikeperry

Keywords: tbb-fingerprinting-locale added; tbb-fingerprinting removed

comment:19 Changed 3 years ago by gk

#15268 is a duplicate of this one.

comment:20 Changed 3 years ago by gk

Cc: arthuredelstein added
Status: newneeds_information

Arthur: There is a bugfix in #13019 claiming to fix this bug (looking at the commit message) which is quite confusing. Even more, it does not affect this bug at all. So what's up with that? And how is #10284 related?

comment:21 in reply to:  20 Changed 3 years ago by arthuredelstein

Replying to gk:

Arthur: There is a bugfix in #13019 claiming to fix this bug (looking at the commit message) which is quite confusing. Even more, it does not affect this bug at all. So what's up with that?

Yes, I should have labeled the patch as #13019. I believe that patch does in fact fix the Date locale problem reported in this ticket, but it is confusing because the problem has nothing to do with the purpose of Greg's test. I propose closing this ticket as a duplicate of #13019, if you agree.

And how is #10284 related?

That looks like another duplicate to me, in the sense that I believe it is fixed by the same patch.

I have opened a ticket (#15299) for regression tests for this patch so we can be sure it's working.

comment:22 Changed 3 years ago by gk

Resolution: duplicate
Status: needs_informationclosed

Ok, we track the effort with the locale leaks in #13019 which had the former patch. This is a duplicate of it then.

Note: See TracTickets for help on using tickets.