Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #10280

Closed (moved)
Open
Opened Dec 03, 2013 by Mike Perry@mikeperry

Torbrowser shouldn't load flash into the process space by default

Bobnomnom or some troll who is excellent at impersonating him seems to be clamoring for blocking all plugins from the Firefox address space, including flash.

In https://gitweb.torproject.org/tor-browser.git/commitdiff/efbc82de0af0c6db05804777777b7177e593f73d, we block everything but flash from entering the address space because it has been shown that arbitrary non-malicious browser plugins can be invasive to privacy. Culprits include AV plugins that report your browsing history to the AV vendor for inspection, and bank authentication plugins that send additional identifiable info to sites under certain circumstances.

Note that neither that patch nor the 'plugin.disable' pref are a comprehensive defense for keeping malicious code out of Firefox's address space. It really only helps if code is generally well-behaved, but has some functionality we simply don't want in the browser at all. In the case of AV plugins, they can seriously manipulate the process address space during initialization in a way that simply disabling them from the Firefox UI won't undo. Moreover, in some cases their hooks and binary patches are so custom-tailored to official Firefox binaries that they have caused crashes when loaded under TBB. As far as I know, this is not the case for flash, which follows the NPAPI interface and doesn't do any other binary patching or hooking.

Truly Malicious code has lots of ways to hoist itself into Firefox, including but not limited to: writing extensions, XPCOM components, or DLLs into the Firefox app or profile directories, injecting DLLs via CreateRemoteThread debugger attachment or the AppInitDLLs registry key, modifying system DLLs, and watching for desktop keypress and drawing events.

I don't understand what threat model bob is using to argue for the additional exclusion of flash. If flash was malicious and you had it installed on your system, it could do all of these things if you ever ran your normal Firefox browser and it got loaded there. It would then have no problems using your user privileges to write the malicious portions of itself into your TBB directory using the above or other vectors.

Perhaps bob can explain the specific issue with flash in this ticket.

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#10280