Search by property

Jump to: navigation, search

This page provides a simple browsing interface for finding entities described by a property and a named value. Other available search interfaces include the page property search, and the ask query builder.

Search by property

A list of all pages that have property "Feature security review" with value "There are security implications to this feature.". Since there have been only a few results, also nearby values are displayed.

Showing below up to 26 results starting with #1.

View (previous 50 | next 50) (20 | 50 | 100 | 250 | 500)

    

List of results

  • Features/Fennec/Android Snippets  + (See [https://bugzilla.mozilla.org/show_bug.cgi?id=774497 bug 774497] and dependencies.)
  • AddonSDKCryptoAPI  + (TBD)
  • Add-on SDK in Firefox  + (The Add-on SDK has gone through multiple security reviews. Should schedule another one to review how/where the code lives and is initiated/loaded inside Firefox.)
  • Services/Sync/Features/Addon Sync  + (The feature follows the same security mode …
    The feature follows the same security model as other sync engines: add-on records are encrypted using Sync's bulk keys (themselves encrypted with the user's Sync Key), and the IDs for each add-on are randomly generated. The entire feature is implemented in JavaScript and runs in the chrome process - the same process as Sync. For the initial feature drop, synchronized add-ons will be limited to: * XPI extensions or themes * from the same application ID as other Sync profiles * installed in the profile directory * installed explicitly by the user (those put in the profile directory by nefarious applications will be ignored - !addon.foreignInstall) * installed from addons.mozilla.org ** In the implementation, the hostname is defined by a preference. the default value is *addons.mozilla.org* Eventually, we'll want to expand to all XPI extensions and will want to handle add-ons from non-AMO URIs. But, these will be covered by separate feature(s) and security review(s). UX has deemed it best for the feature to have no explicit UX in the browser, as Sync should be transparent. However, modification of add-ons could result in changes in browser behavior. Toolbars and buttons could appear/disappear "randomly" (corresponding with when Sync runs - which is transparent to the user). Tabs could be opened for add-ons which open tabs on install events. While these aren't security vulnerabilities, they could be perceived as such. "Why is my browser changing - was it hacked?" UX rationalizes it by saying that any add-on behavior must have been triggered by user behavior somewhere. This is true. However, a user might be surprised to see add-ons magically being changed upon (transparent) upgrade to Firefox X. Upon add-on modification, about:addons should reflect the change immediately. If a user's Sync server credentials (but not the Sync Key) are compromised, the server records would reveal the last modified time of individual add-on records. Without access to a Firefox profile, it would be unknown which add-on each record corresponded to. This data leakage is minor and is on par with other leakages currently in the Sync service. Sync transmits each add-ons ID between devices. The add-on ID is looked up on addons.mozilla.org. Assuming it is found, Firefox will download the extensions or theme from addons.mozilla.org and install it. The installation process uses existing AddonManager APIs. This will result in more requests to addons.mozilla.org. However, such requests shouldn't be traceable back to Sync. We (theoretically) already trust the privacy model of addons.mozilla.org, so even if data is leaked, it should be no big deal. This is the first component of Sync which will indirectly communicate with a non-Sync server (addons.mozilla.org). Sync will be talking with it via the AddonRepository JS APIs. Sync assumes those APIs are doing the proper things to secure against MITM attacks, etc.
    hings to secure against MITM attacks, etc.)
  • Services/Sync/Push to device  + (The feature will be built on top of Sync a …
    The feature will be built on top of Sync and therefore Sync's data security model applies. Each tab sent between devices will result in a "tab state" record being uploaded to the Sync server. The ID of this record (the part that appears in the URI) is randomly generated. The payload of the record is encrypted on the client using the private Sync Key. The ID is transferred between clients by a modification to the client's record. This client record is also encrypted locally using the Sync Key. In other words, no data is readable without the Sync Key. The Sync server does leak timing information when "send tab" records are uploaded. However, we currently have timing leaks from other data sources (e.g. history). By looking at the upload time of the "send tab" record and the modification time of a specific client record, it would be possible for a server operator or person with authentication credentials (but not the Sync Key) to glean when a tab is sent to a specific device. This is slightly worse than the current world, where the server only sees client record modification in rare events (e.g. wipe client requests) and the actual record modification may not be determinable. When a client receiving a tab downloads its client record, it will see the command to load a tab. The client will then download the tab state record and process it. On the next sync, the client record for that device will be replaced with one not containing the send tab command. Timing information could then be used to determine when a device was used. Again, this is similar to how existing commands work. The biggest difference is send tab commands are expected to be sent with a relatively higher frequency than existing commands. The UX will live in tabbrowser on Firefox, the icon sidebar thing on mobile, and whatever that button grid is on tablets. The UX will call into Sync's code with an instance of a tab/browser to send. Sync will collect a tab's form data, session cookies (attached to the host belonging to the URI of the main "frame" only - at least for starters), and position in page. It will run with Chrome privileges, just like Sync. It likely calls into Session Store to perform some of these actions, but it may access low-level APIs as appropriate. Once data is collected, it is encrypted and uploaded to the server on the next sync. The Sync engine will notify an nsIObserver upon receipt of a send tab command. The observer handler will live in browser/components/nsBrowserGlue.js on Firefox and browser.js (or similar) on Fennec (and whatever the Java equivalent is). The observer handler takes care of creating the new tab from the decoded record data. Currently, this is implemented as a function call into Sync. This all happens with Chrome privileges.
    . This all happens with Chrome privileges.)
  • Features/Firefox/Network Installer  + (The installer will be downloaded securely and then itself ensure the integrity of the binaries.)
Retrieved from "https://wiki.mozilla.org/Special:SearchByProperty/:Feature-20security-20review/There-20are-20security-20implications-20to-20this-20feature."