ftp:// on Windows can be used to leak the system time zone

z3t reported via HackerOne that the system time zone on Windows can get leaked by using ftp://.

When using the ftp:// protocol, directory listings contain timestamps converted to the system timezone.. These timestamps can be extracted by a script on a same-origin FTP hosted HTML page, allowing detection of a user's system timezone.

added GeorgKoppen201909 TorBrowserTeam201909R component::applications/tor browser owner::tbb-team priority::high resolution::fixed severity::normal status::closed tbb-fingerprinting type::defect labels

duplicate of #30427 (moved) ?

Replying to Thorin:

duplicate of #30427 (moved) ?

I don't think so. The time zone is not leaking on non-Windows platforms while the UI locale is leaking on all we support.

I'm curious, how is it possible to read contents of ftp from a webpage? I tried an iframe, but cannot access, it's a RestrictedWindow... Was there a PoC in the original HackerOne report?

upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=1560574 incl. Gary's patch

Replying to acat:

I'm curious, how is it possible to read contents of ftp from a webpage? I tried an iframe, but cannot access, it's a RestrictedWindow... Was there a PoC in the original HackerOne report?

http://ritter.vg is not same origin to ftp://ritter.vg but if you go to ftp://ritter.vg/example.html that will show a webpage that can then iframe ftp://ritter.vg/uploads/ and they are same origin so it can read the directory contents.

(Addresses illustrative only)

bug_30800 (https://gitweb.torproject.org/user/gk/tor-browser.git/commit/?h=bug_30800&id=b21da86362c76a231901e6733adee7512579ff06) has the backport to esr60 of Gary's patch. It fixes the problem for me, nice work! I am still not sure about why only Windows is affected to begin with, though, but did not dig deeper into the code yet.

I guess we could try to test what we have in the alpha, provided the patch looks good to us?

Trac:
Keywords: N/A deleted, GeorgKoppen201907, TorBrowserTeam201907R added
Status: new to needs_review

I'm quite sure Gary said there was something missing/wrong in the patch in the uplift meeting, so I asked him about this (waiting for response). Meanwhile, by looking at it and trying an unpatched Firefox in Windows, I can see that one of the columns has a uint64 timestamp that seems to be timezone dependent (and that I think the patch is not addressing). It's the sortable-data property of the 3rd column, not visible. So this might be the issue Gary mentioned.

Besides, I'm not sure why we could not use UTC instead of GMT when resistfingerprinting is on (at least that's the behaviour on Linux for me, and it does not leak the timezone).

Besides, I'm not sure why we could not use UTC instead of GMT when resistfingerprinting is on (at least that's the behaviour on Linux for me, and it does not leak the timezone).

Sorry, obviously this does not make any sense since they are synonyms, forget about it :)

Trac:
Status: needs_review to needs_revision

FWIW, UTC and GMT are not synonyms. RFP uses UTC.

Trac:
Keywords: TorBrowserTeam201907R deleted, TorBrowserTeam201907 added

That landed recently on mozilla-central. Thus, I think we are good now? bug_30800_v2 (https://gitweb.torproject.org/user/gk/tor-browser.git/commit/?h=bug_30800_v2&id=a2e76dee549c9efb60bfa13c0e6e4e5f8b5edd76) has the backport for review.

Trac:
Cc: N/A to acat
Keywords: GeorgKoppen201907, TorBrowserTeam201907 deleted, TorBrowserTeam201909R, GeorgKoppen201909 added
Status: needs_revision to needs_review

Looks good to me.

Thanks. Merged to tor-browser-68.1.0esr-9.0-2 (commit a2e76dee549c9efb60bfa13c0e6e4e5f8b5edd76).

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

closed

moved to tpo/applications/tor-browser#30800 (closed)