Opened 7 years ago

Last modified 8 months ago

#4338 needs_revision defect

TBB creates Mozilla folder in user folder

Reported by: cypherpunks Owned by: mikeperry
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: backport-to-mozilla, tbb-disk-leak
Cc: Shondoit Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The Tor Browser Bundle creates a Mozilla folder in the C:\Users\[username]\AppData\Roaming folder when the browser starts. The folder does not appear to be used for anything.

It would be better if no such folder were created in the 1st place as to leave less trace that tbb has been used on the computer.

Child Tickets

Attachments (1)

clean-appdata.diff (664 bytes) - added by Shondoit 7 years ago.
Proposed fix for cleaning AppData

Download all attachments as: .zip

Change History (17)

comment:1 Changed 7 years ago by arma

Component: - Select a componentTor bundles/installation
Owner: set to erinn

comment:2 Changed 7 years ago by Shondoit

Cc: shondoit+trac.torproject@… added

Changed 7 years ago by Shondoit

Attachment: clean-appdata.diff added

Proposed fix for cleaning AppData

comment:3 Changed 7 years ago by cypherpunks

Even with the proposed fix, it is still evident that Tor (or a Mozilla browser) has been used on the computer, because the information still exists on the harddrive.

Assuming that the adversary only gains access to the computer after Tor has been used, and finds no Tor installation (or Mozilla installation), then they have more certainty that there is somewhere a hidden USB stick containing Tor or other interesting programs.

Additionally, by not trying to create the Mozilla folder, it avoids certain weird permission issues where the user does not have full access to her user folder (such as some setups in internet cafes).

comment:4 Changed 7 years ago by Shondoit

The out-of-the-box version of TBB creates the folder during startup of Firefox.
But it turns out that when Torbutton is disabled, the folder will not be created. At least not during startup.
However, when later on the Add-ons manager is opened, the folder is then created as well.

Using SysInternal's Process Monitor I could see that %AppData%\Mozilla\ was created right before %AppData%\Mozilla\plugins\ was attempted to be accessed.
I'm guessing that the creation of the Mozilla folder has to do with Firefox' handling of plugins and that Torbutton is only triggering it at startup.

My TBB did not have any plugins installed and had only the three default add-ons.

comment:5 Changed 7 years ago by StrangeCharm

Cc: StrangeCharm added

comment:6 Changed 7 years ago by Shondoit

Keywords: backport-to-mozilla added

Filed a ticket with Mozilla for this (#704870)
In the mean time, we can look if we can redirect the folder or otherwise prevent it's creation.

comment:7 Changed 7 years ago by mikeperry

Component: Tor bundles/installationTor Browser
Owner: changed from erinn to mikeperry

12:41 < Shondoit> I found out that when, in torbutton.js, line 4180:

istream.init(chan.open()); is commented out, that the Mozilla
folder is not created during startup.

The line in question is just a call to read the contents of a chrome url (specifically chrome://torbutton/content/jshooks4.js). It must trigger some kind of initialization code that creates the directory, but I have no idea why or how.

comment:8 in reply to:  7 Changed 7 years ago by Shondoit

Replying to mikeperry:

12:41 < Shondoit> I found out that when, in torbutton.js, line 4180:

istream.init(chan.open()); is commented out, that the Mozilla
folder is not created during startup.

The line in question is just a call to read the contents of a chrome url (specifically chrome://torbutton/content/jshooks4.js). It must trigger some kind of initialization code that creates the directory, but I have no idea why or how.

The reason this works is because the script errors out before it can trigger the folder creation.
If you were to introduce a syntax error the script would not run and also not trigger the creation.
Basically, it was a red herring.

comment:9 Changed 7 years ago by Shondoit

I managed to pinpoint the creation to the first call of getPluginTags in torbutton_toggle_plugins().
You can verify this by adding 'alert("Before");' and 'alert("After");' before and after line 1520: 'var P=PH.getPluginTags({});'
This indicates that at least a call to 'nsPluginHost::GetPluginTags' creates this folder.

comment:10 Changed 7 years ago by mikeperry

Milestone: TorBrowserBundle 2.2.x-stable
Priority: normalmajor

comment:11 Changed 7 years ago by mikeperry

Keywords: tbb-disk-leak added

comment:12 Changed 7 years ago by Shondoit

Cc: Shondoit added; shondoit+trac.torproject@… removed
Status: newneeds_review

Made it into a git branch:
https://github.com/Shondoit/vidalia/tree/bug4338
Marking it for review, but would probably be best left open after the patch is applied.

Also, if anyone feels up for it...
I don't really have the time nor expertise for this, and Mozilla doens't seem too eager either.

comment:13 Changed 7 years ago by mikeperry

Status: needs_reviewneeds_revision

Hrmm.. Your patch is not really a fix.. Removing the directory after the fact is not the solution. We should try to figure out how to alter Torbutton to prevent it from being created in the first place.

Also, right now this is only considered a smoldering ember rather than a serious issue.. No actual client data is stored in this Mozilla directory, right?

comment:14 in reply to:  13 Changed 7 years ago by Shondoit

Replying to mikeperry:

Hrmm.. Your patch is not really a fix.. Removing the directory after the fact is not the solution.

Right, I was supposed to throw in the word 'workaround' in there somewhere.
That's why I mentioned the ticket should be left open.
However, this does not mean it shouldn't be applied for the time being, seeing as TBB as it is now leaves traces outside it's own folder. (comment #13)

Also, right now this is only considered a smoldering ember rather than a serious issue.. No actual client data is stored in this Mozilla directory, right?

It's been a while since I did something with this. It leaves nothing in the directory *after* the session is closed, but I don't remember if data is written *during* the session.

We should try to figure out how to alter Torbutton to prevent it from being created in the first place.

Torbutton seemed to not be the cause but rather a trigger for the underlying cause.
If I recall correctly, even with torbutton disabled, it was triggered by opening the 'add-ons' page as well.
But like I said, it's been a while.

comment:15 Changed 3 years ago by bugzilla

Component: Firefox Patch IssuesTor Browser
Milestone: TorBrowserBundle 2.2.x-stable
Severity: Normal

How did this ticket change its Component without any record in comments?

comment:16 Changed 8 months ago by StrangeCharm

Cc: StrangeCharm removed
Note: See TracTickets for help on using tickets.