This is the context: Suppose there is a plug-in, P, available at the Mozilla Firefox add-on site.
Consider a malicious user that modifies P, for example, to make it deviate from the normal behavior. My first question is:
Could the Firefox browser detect that the plug-in is not the original one (i.e., the one that was downloaded from Firefox site? If this can be detected, could the Firefox browser disable the (modified) plug-in?
Now consider the case of a Web site that interacts with the plug-in P. For example, the site allows access to the web content only if the plug-in is original (it has not been modified).
My second question is:
Could the site be able to detect that this malicious user modified the plug-in?
Firefox detecting changes
All extensions which are downloaded from AMO are cryptographically signed by Mozilla (link 2). If the extension is modified in any way, Firefox will automatically detect that there have been changes and will disable the add-on.
However, if the user is running Firefox Developer Edition, Firefox Nightly, Unbranded Beta, or Unbranded Release, they can change a preference such that the modified extension will not be disabled. The modification will still be detected, and the user informed in about:addons (Ctrl-Shif-A, Cmd-Shif-A on OSX). It is also possible for the user to download the source code for Firefox and compile their own version which disables add-on signature checking.
Temporary add-ons
The normal release and beta versions of Firefox do not permit the user the option to permanently install and run extensions which have not been signed, or where the extension has been changed after signing. However, they do, along with all other versions, permit an extension to be loaded as a temporary add-on even if unsigned, or changed. This makes it impossible unsigned add-ons which require a browser restart in those versions of Firefox.
Summary
Mozilla singing add-ons is intended to prevent add-ons, which are malicious, or that just have not been reviewed by Mozilla, from being downloaded and installed by naive users. Thus, to install an unsigned, or changed, add-on, the user has to jump through extra, inconvenient steps (not use a branded release or beta Firefox, or use a temporary add-on install). However, signing does not, and was not intended to, prevent the user from intentionally changing an add-on and not being able to run it.
Website detecting that the extension has changed
No, assuming that the modifications to the extension are intentionally being hidden, there is no guaranteed way for the web page to detect that a change has occurred. The modified extension can spoof any information that is provided to the web page by the original extension code. You can make this hard to do, but it can not be guaranteed.
You have not mentioned why you are wanting your website to be able to detect these changes. Thus, without guessing as to the purpose, it is not possible to provide you with reasonable alternatives.
You're asking for DRM, i.e. the ability to verify that a remote piece of software running on general purpose computing hardware is executing the code which it itself claims to be executing.
This is not possible, since the claimant can always lie and run any code snippet used for interactive authentication in some form of emulator.
Depending on what you're actually trying to achieve you should use user-specific authentication, i.e. tie site access to some token or password instead of the addon, or treat all inputs by the addon as unstrusted and verify them against whatever protocol they should follow.
In short: Validate data, not code.
Related
Does anybody have the same problem? New extension with verified domain and enabled inline install after clicking on button with chrome.webstore.install();cause redirect to chromestore with get parameter ?utm_source=inline-install-disabled
I recently received the following email from Chrome Web Store Developer Support:
In addition to the existing extension-level protection, our expanded
enforcement will also use machine learning to evaluate each inline
installation request for signals of deceptive, confusing, or malicious
ads or webpages. When we find those signals, we'll selectively disable
that one inline installation request and redirect the user to the
extension's page on the Chrome Web Store. This selective enforcement
will not impact inline installation of that extension from other,
non-deceptive sources. Developers will not be notified of this
enforcement, as it happens on an as-needed basis.
Are you serving any ads on your site or doing anything else that might be perceived as a grey area by ML?
If you're being blatantly deceptive, it would appear that you've been found out. If not, and you're genuinely confused, a possible first step would be to scrape your site of any ads or injected content altogether to see if you're able to regain Google's trust.
We have authored a Chrome extension and would like to ensure that our extension does not at any time participate in being sync'd using Google Account synchronization, even if the user has specified in the Advanced sync settings dialog that extensions be sync'd. Is there a way to prevent this sync'ing on a per-extension basis? Is there some setting we could place in the extension manifest file to accomplish this? Or other way to accomplish this?
If that is not possible, can we force the Extensions checkbox to always be unchecked and unalterable by the user, using enterprise-level techniques such as Group Policy Update? This is not optimal, since we only want to stop the sync'ing of our extension, and not prevent sync'ing of all extensions.
We do see that the SyncDisabled policy registry setting is available to us, but that looks like it will disable ALL data synchronization including Apps, Extensions, Settings, History, etc. This is even less desirable to us, since we don't want to affect other synchronization -- we just want to prevent only our extension from being sync'd.
The use case for this involves the following:
A corporate user installs Chrome on his work computer. Our extension is useful in the enterprise environment and is installed on Chrome.
At some point, using the Chrome browser, this user logs into his personal Gmail account. He has set up his Google Account to turn synchronization on.
Now when this user, using his home computer and Chrome browser, logs in to Google, he will find that our extension has also been installed on his Chrome browser at home -- this is not desirable, since our extension has no usefulness in the home environment. Moreover, the user may consider the presence of our extension an unwanted intrusion into his home computing environment.
The only remedy for this user would seem to be that he could go to the Advanced sync settings and uncheck the Extensions checkbox, but then he would lose the benefit of extension sync'ing of other extensions, which he may want.
Well, if you're doing it in a corporate / managed environment, you don't need to publish your extension on Web Store at all (thus preventing the sync) if you can use Group Policy.
Any extension in ExtensionInstallForcelist will be installed even if it (and its update manifest) is hosted outside Web Store. This will prevent the extension itself from syncing (though will probably still allow chrome.storage.sync to function for it, which is a plus).
Other than that, I don't think there's a way to prevent an individual Store-hosted extension from syncing.
My question is how do third party installer installs addons in the browser like toolbars and able to set homepage and other browser properties??
I want to make an addon which get installed in browser in same way..
is it possible??
In principle, installing extensions along with other software is possible. I'm describing the procedure for Windows.
The following conditions have to be met:
You must be able to write to the HKLM registry subtree (needs Admin rights)
The extension must be published on Chrome Web Store
The machine must be able to download the extension from Web Store
If those conditions are met, you can do it according to the procedure described here. Basically, the installer must create a registry key that will trigger Chrome to download the extension on next launch.
That said, Google has gone to great pains to prevent silent installs and avoid browser settings hijack. Such setting overrides are a weapons race and Chrome is tightening its defenses. Ask yourself whether it's ethical to install your extension this way.
It will probably annoy your users and will flag your extension for more meticulous checks by Google. Remember that Google can disable any extension hosted by the Web Store if it violates its policies.
Also, be mindful of the single purpose policy. A toolbar that also overrides search/homepage/settings will be frowned upon. At a minimum it should be separated into several extensions, at a maximum - don't do it.
An extension can override, say, a homepage, but it's very restrictive. The extension must be in the Web Store as above, and any override pages must be verified for ownership for the Web Store developer account. All in the name of security and comfort of the users.
I may be a bit of paranoid when it comes to installing chrome extension that request access to all my tabs and data. While a extension may be safe for the moment, a simple auto background update can make it a malicious virus and you won't even get notified about updates.
I would like to specifically whitelist all my extension to access the content pear webpages bases. Is there any such tool out there already (natively perhaps) before i start hacking my own extension to control it on my own.
That would leave me to my next question. Extension can be a bit secured running sandboxed environment and have no access to the "real" filesystem (not the virtual sandboxed filesystem) but could i write a NaCl plugin and have have full access and change the manifest file to change the content_scripts settings? if so, could you point me in the right direction?
I'm not sure to understand clearly your question, but let's calrify some things about extensions and how they can be dangerous:
First: If an extension updates and want to have new authorisations, Chrome will warn you and you can choose if you want it to be updated
Second: Chrome sandboxes extensions running on your computer
Third: The only authorisation that may represent a real danger for your computer are the ones requesting authorisation to "Access all data on your computer"
.
.
.
If you are really worried that some extensions may represent a danger for you (and I understand you), you can restrict them to run on specific webpages by doing the following:
1. Go to the extensions folders [C:\Users(YOUR USERNAME)\AppData\Local\Google\Chrome\User Data\Default\Extensions(APPID)] and open the manifest.json file with any text editor
2. In "content_scripts" declaration, in "matches", specify sites where the extension will ONLY work on [ex:*://google.com/* will make extension be active ONLY for google.com]
You can even be more precise and set specific URLs/HTML pages (see more: https://developer.chrome.com/extensions/match_patterns)
Hope it helps!
If it doesn't, please clarify your question again.
I've written a NPAPI plugin and I want to implement an NSIS installer that can install the plugin automatically.
I've googled a lot and found that from Chrome browser v25, *.crx package installation using the Windows registry does not work any more(the installed extension will be disabled by default). It seems that
Google does not allow any automatic extension installations without being approved by user.
However, I also found that if I install the plugin dll (instead of crx) on user's local machine and write reg keys to
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\MozillaPlugins\#myplugin.com/myplugin with correct dll path, the plugin could be installed automatically as long as my user downloaded and executed my installer, without any notification that the new plugin was going to be installed.
My question is that why my installer works? Is it in contradiction with Google's policy?
Shouldn't all the plugins installed under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\MozillaPlugins be blocked or disabled by default?
Extensions and NPAPI plugins are very, very different, as are the associated risks to users, and they therefore have different policies.
Extensions can't be silently installed because that ends up being used to install malicious extensions that do things like change browser settings and make them hard to change back, easily harvest sensitive information from sites users visit, inject extra ads on every site the user visits (and/or replace ads that support sites with ads that just pay the malware authors), etc.
NPAPI plugins, on the other hand, do absolutely nothing in the browser unless specifically loaded by a page. They aren't particularly interesting as malware, because the added capability that NPAPI plugins give you is the ability to run native code. But if a malware author can get someone to run an installer to install the plugin, they could just as easily install something else instead that runs native code continuously in the background, rather than only when a user visits a site that triggers a plugin (and they can much more easily hide that than a plugin, which has to be in a known location, and shows up in Chrome).
The danger with NPAPI is around exploits of already-installed, non-malicious plugins, whereas the installation of malicious extensions is a real issue.