Adware vendors buy Chrome Extensions to send ad- and malware-filled updates
arstechnica.com
arstechnica.com
Auto updating anything but the most critical and most trusted software is absolutely bone-headed and we're going to look back and wonder how we could be so stupid.
Yep. It's kind of mind-blowing that Crome defaults to auto-updating extensions, then lets just anyone upload new versions of them. (Is it even possible to disable this idiocy?) I take some perverse joy in the fact that someone has "monetized" the auto-update treadmill. Maybe it will encourage people to think about the consequences of installing random code to your computer whenever someone else decides to do so.
The reason Chrome includes this functionality is because the hand-rolled solutions people come up with frequently have security problems.
Also, auto update gives good developers a way to fix their own security bugs when they are discovered.
The autoupdate feature exposed to Chrome extensions is not there to make autoupdate possible, it's there to prevent developers from shooting themselves in the foot by implementing their own autoupdate insecurely. It's similar to a platform providing crypto libraries rather than letting developers implement crypto themselves.
The only way to try and prevent software from autoupdating is with manual review, which is what Apple does with iOS. However that has a whole other host of problems.
As for security model: I don't know how to measure "meaningful", but Chrome extensions have the most fine-grained security model of any extension platform. In fact, it is more fine-grained than most general purpose software platforms:
http://developer.chrome.com/extensions/permission_warnings.h...
The problem that started this thread is real, but it is not solved by disabling autoupdate (which is impossible) or adding more "security model" to the platform.
In fact the problem is very deep: How do you balance the desire to allow flexible software on your platform (adblocking, network stack interjection, manipulation of the user interface, etc), with the desire to limit the potential harm malicious actors can do? These two goals are in conflict. Existing best answers that humanity has come up with include some combination of "manual or automated review", "social signals" (stars, reviews from your network, etc), "blacklisting", "controlling access to the platform" (iOS apps can only be deployed in large numbers through the store), and "limit the power of the platform where possible with clever user interfaces" (the file upload button in HTML is a classic example).
You can remove eval() (In fact eval() is disallowed in Chrome extensions, for different reasons).
But how do you prevent an extension from including an interpreter for some other language and simply downloading and interpreting code in that language? This isn't crazy. It's common for games to include interpreters, for example.
Including an interpreter for a simple language is just one step in complexity beyond downloading configuration files. Is downloading configuration files that change the behavior of the code forbidden in your proposed system too? How is that accomplished?
"If Google can manage to allow machine code downloaded over the internet to run securely like it claims, I'm sure it can handle a little javascript."
NaCL has the same properties I'm describing. NaCL enforces a sandbox on what a hunk of code has access to; it doesn't enforce that that code won't change its behavior over time, possibly in response to data from the network. That is not possible to do.
The other problem with the security model is that all extensions are seemingly created equal. I would think that a large majority of extensions do not require access to any external resources besides the ones downloaded from the webpage itself. Think of a youtube downloader, flashblock, etc. These types of extensions should have a different security model that is constrained to restrict any web request calls besides to the domain of the page and perhaps any domains that page calls (to take into account cdns). These types of extensions shouldn't need any consideration of security implications to install. There's no reason why a youtube downloader should have the potential to steal my passwords down the line. More involved extensions that would require generic http requests could have the warning about data access.
I see in your profile that you know a thing or two about chrome extensions, so I will defer to your expertise on whats possible. It just seems like with the proper constraints for different levels of access one can have much greater security than we have now just treating all extensions the same.
We might propose that we could prevent these hand-rolled systems by restricting eval(). Well, we already restrict eval for different reasons. What we see is a lot of people working around the restriction by injecting code into websites (!!).
My bet is that basically any significantly sized extension would implement a workaround for any autoupdate restriction we tried to employ. Developers really like the ability to update their product, and the workarounds are not that hard. And these workarounds would be worse than the original problem - that sometimes good people turn bad.
It would also destroy the value that autoupdate provides which you are forgetting about: most of the time it is used by good people to do good things. We frequently find extensions with security problems, tell the author, and then they fix and push them to users. Without autoupdate this wouldn't be possible.
===
As for your proposal for how to restrict the levels of access extensions have... As I said above, we do this kind of thing already. You can read all about it here: http://developer.chrome.com/extensions/permission_warnings.h.... We have a very granular security system.
For example, it has been always been possible to write a youtube downloader Chrome extension that only has access to youtube.com.
Flashblock would theoretically be possible with the upcoming declarativeWebRequest API (http://developer.chrome.com/extensions/declarativeWebRequest...).
However designing the right APIs that have narrow risk, yet are flexible enough for developers to want to use remains a difficult problem that is unsolved except in specific cases.
Not to mention we need better and finer grained permissions for extensions in general, now that we use so many web apps with crucial data.
My second user account is logged into basic services like HN, reddit, amazon and has only adblock and disconnect installed.
A third user is not logged in anywhere and has adblock and a half-dozen other extensions installed including UA switcher. No plugins installed and cookies + cache cleared every day.
4th user has all the anonimity extensions installed and has privoxy + tor set as the proxy
I use Facebook in a completely different browser again, YouTube and video watching in yet another and development in chromium.
7 or 8 different cookie stores, and a throwaway temp email account associated with the 3rd and 4th user for signing up to services.
Start out by creating a separate user for browsing sites and eventually develop your own way to split up your web browsing profiles.
This can get a bit messy when you try and access from tablet or mobikle , but I'd rather not have a single large profile and a huge exploit surface and sacrifice browsing history and remembering passwords.
Once you get used to it you instinctively switch without thinking about it
I also created an app for OS X that creates temporary throwaway browser sessions for any supported browser you have installed:
https://github.com/nikcub/tmpbrowser
Makes it easier than using command line options and creating users
A simple way to do this is to use different brands of browser, e.g. Gmail in Chrome and everything else in Firefox. But... if you really prefer one browser over another, for all use, then the separate profiles thing works.
Note that in Chrome, this is now confused by the ability to change Google account log-ins. That is not a separate, browser-level profile with separate configuration.
Instead, you are looking for the command line invocation argument --user-data-dir (in *NIX, at least; IIRC the flag name may differ slightly in the Windows version).
For Firefox, there is the -p flag. IIRC, you have to combine it with another flag in order to ensure both that the profiles are running in separate invocations and that you can be prompted to choose what profile to use when you invoke Firefox.
Of course, you can create menu items / icons for these invocations to make them "clicky" and avoid having to go to the command line and enter them each time, if you prefer.
P.S. Yes, this will help you less if you insist upon clicking directly on/through links that are are e.g. mailed to you or, if you have Facebook in its own "box", posted on Facebook.
From that perspective, having per site browser extension variability might still be useful. But then, you're still looking at also controlling referer passing, cookies and other local data, etc., etc.
firefox -no-remote -ProfileManager
https://developer.mozilla.org/en-US/docs/Mozilla/Command_Lin...
It's also a good idea to use different themes per profile (and I see you suggested it too).
The separate browser solution does protect from tracking, but with the security threats of today, like these malicious extensions with access to all your data, I've become desensitized to mere tracking.
An extra cue, when the border background, tabs, etc. look different in one versus the other. Still hardly foolproof...
(I use FF.)
> Because Google Chrome does not control how extensions handle your personal data, all extensions have been disabled for incognito windows. You can reenable them individually in the extensions manager.
Keeping your gmail tab in an incognito window might be a good approach.
https://chrome.google.com/webstore/detail/ghost-incognito/ge...
Don't you mean a PR on the Chromium project?
It sounds like Google needs to flag ownership changes and NOTIFY USERS about them
before the next auto-update of that extension.
------------
NoteBuddy has been transferred from Joe Garage to Russian Mafia LLC.
Do you want to keep this extension enabled?
[ Da ] [ Nyet ]
-----------
- DaveSimmons
Extensions are reaching the wild-west of Play and no one's happy about that except malware/adware authors. If Google continues to serve more free users than their quality capacity (already a problem with every other service they offer), it won't be long before people move on.
And they will move on. Contrary to what most people believe, no one rules one domain forever. Whether it's the big iron of IBM, telecom of Bell, OS of Microsoft or the services of Google. Someone else will eventually wrestle in on your domain.
I'd lean towards using a finer-grained permission model for extensions, and javascript in general. As far as I know, most extensions now can only request permissions to run arbitrary JS on every page you visit, and send arbitrary AJAX to any URL. Perhaps we could do a better job of locking that down. Have no such thing as a permission to AJAX any URL, but instead make AJAXing any particular TLD a new permission. Maybe we can also only allow access to DOM elements originating from particular domains. Then you could keep auto-update, but require a new user authorization for any new URL/domain access that an extension needs. It'd probably get pretty complex, but I think we could put together something reasonable. But then the other problem is the pile of plugins out there already with those arbitrary permissions. Maybe you could let them stay, but not allow any updates without switching to the new permission model?
The Google model of an auto-updating but un-QA'd app store doesn't work for me, because it combines two things I really don't see as compatible: 1) low-friction updates; and 2) installation of arbitrary un-reviewed code from the internet. If you're going to do #2, then I want the friction of downloading a new executable. I want to go to a website, see if the company still exists, read the release notes, generally be cautious about installation of random executables off the internet. But if you're going to do #1, then since the updates are supposed to apply without significant review by me, someone else has to be vetting what goes into the repository for at least minimal non-evilness standards.
I agree on this.
The best solution for now would be a meta-extension that checks if you have compromised extensions installed and disable them.
The blacklist could be compiled based on the Store feedbacks (ratings dropping sharply? disabled.), a reporting system from the app, and also using automatic testing. For example run the extension on a sandboxed machine and check for requests to known shady domains.
I uninstalled noscript years ago when it started updating twice a week with apparently miniscule changes just to pop up its ad filled landing page. Its a fucking javascript blacklist/whitelist app, why on earth does it need to update? If I wanted a "browser security suite" (what noscript currently bills itself as) I'd download that specifically.
Sites like pinterest have extensions that request these permissions, when they don't even need them. There's a way to have the extension only have access to the site you're on when you CLICK somewhere in your toolbar.
There are fine grained permissions and optional permissions to specific hosts and ports and URL patterns. It's all very well thought out.
The problem is with users.
For example, I have an extension that enables autocomplete on all web pages: https://chrome.google.com/webstore/detail/autocomplete-on/gd..., and it has access to all data on all websites. People install it every day, I don't know why. I would never install or trust anybody else with such an extension. I have to manually clone any extension I like and upload it to the chrome web store; that way I know it's not going to auto update and do nefarious things.
With how the update system works[1], when requesting new permissions the extension is disabled until manually reenabled. If there's even a slight possibility you may want to request access to additional sites in the future, you basically have to request "all websites" to prevent this from happening.
Since Chrome 16 there have been optional permissions around (so you only request permissions when they're needed, preventing the extension from auto-disabling), although that introduces additional overhead beyond simply requesting everything in the manifest file.
The extension update system should probably work more along the lines of that in Android - it auto-updates if the new version needs no additional permissions, but requires user input when new permissions are required. The current[1] state of auto-disable-on-update isn't ideal from either a developer or user position.
[1] as of about a year ago when I last tested this
Still, I feel that using optional permissions and pointing out to the user why they would want enable the new permissions is the best option. Yes, it's more work for the developer.
I just released an extension to help identify high risk installed extensions: https://chrome.google.com/webstore/detail/privacy-guard/edca...
Of course, then you need a solid extension update system where there's some way to alert the user of when an extension needs new permissions, and have them see and authorize them before the update goes active. Hopefully something like the way that Chome updates work now - instead of throwing a modal dialog at the user at some random time, have a tick or light in the UI somewhere that they need to do something.
I'm using "Super Awesome New Tab Page" for Chrome, and since few days ago random ads started popping on youtube, ebay, dx.com, amazon etc ... Took me ~30 mins to figure out which extension it was, and removed it... They also injected <script> tags to ALL websites I visited (that loaded external JS), tracking my history and they could easily put any form/input logging and silently insert keylogger into my Chrome if they wanted. I have reported the extension then, but nothing happened yet.
Link: https://chrome.google.com/webstore/detail/awesome-new-tab-pa...
I had at least one app where I didn't pay close enough attention to the permissions it required upfront and at some point it started injecting ads into random pages (it was a stopwatch, by the way). I guess the only way to effectively counter this is a better permission system.
And for Google to allow this to happen is unconscionable.
I declined their offer.
Good on you for turning that down. You've saved your users a lot of aggravation.
Second, Google needs to modify their policy towards Chrome addons to disallow ad injections and all user tracking.
There should be a clear demarcation between addons and "apps" in the Chrome store. Apps can be legitimately supported by ads. Addons shouldn't be.
* http://blog.chromium.org/2013/12/keeping-chrome-extensions-s...
Similarly, there should be a log for AJAX requests made by the extension directly.
It's easy to convince yourself you have been cheated when you know your extension has over 1M+ downloads and you only have ~!$100 sent to your donation button.
After I re-released it on the Chrome Store, now I get emails trying to buy "my" extension from me.
If it happened enough the buyers would start being more cautious. The bar for minimal installs will go up and more proof will be expected. Soon enough the buyer's intentions will be clear to any extension owner.
> The bar for minimal installs will go up and more proof will be expected.
Or the Store would be flooded with infected cloned extensions that some idiots will install anyway.
> Soon enough the buyer's intentions will be clear to any extension owner.
That's not the problem: developers could trivially be informed of this risk when they submit their extension on the Store.
btw: my parents end up with Chrome every time I come by on the Windows. Installed through some update (Java maybe?). Is there any way to block this without taking all installation rights from them?
My guess would be the tooltip-like thing that Google puts on its search page telling them to "make the web better with Chrome." I've never clicked on the thing, but it probably changes your default browser and installs a bunch of shortcuts.
Don't run extensions from sources you don't trust in a browser profile you need to trust.
I have one profile for development and one for browsing. development browser can get any old extension but the normal browser gets extensions from known, trusted companies like Google and LastPass.
http://www.reddit.com/r/IAmA/comments/1vjj51/i_am_one_of_the...
Beyond helping determine why you're now seeing extra ads, this could help debug why certain sites are no longer working.
Hardly, if this kind of thing is allowed in their marketplace.
>Hardly, if this kind of thing is allowed in their marketplace.
They'll move on this just like they started actively patrolling the Play Store for malware. Because they are a trusted source, even if they aren't an FSF definition of trusted source.
With proprietary code, you're restricted to audits done by those whom the code author has allowed to do so (or who have surreptitiously obtained the source ... and having done so, put themselves at legal risk by disclosing their findings).
The evidence seems to be that this does actually work - people do look, and find out suspicious looking issues. However, that is insufficient to protect users of extensions that were previously trustworthy and then become malicious.
Follow http://superuser.com/questions/290280/how-to-download-chrome... in order to download the crx file manually.
Then unzip it and vet it manually to be clean.
Copy it in a folder, enable extension developer mode in Chrome and install the local copy of the extension.
No autoupdate, everything's fine.
Unfortunately Google plans to disallow local extensions, which is a major disaster and very evil: http://thenextweb.com/google/2013/11/07/google-block-local-c...
What happened to that?
So, pardon my french, but no freaking way do I want any local Chrome extensions allowed by default anymore.
For extensions from the Chrome store, perhaps Chrome should make updates more like on Android, where you are notified and can click for more info.
That code could, I dunno, run a local HTTP/S proxy (install a trusted cert) and MiTM your HTTP requests and inject ads that way. Or about a million other things.
And it's funny Chrome is trying to prevent apps from doing that, when they themselves do the same thing: In Windows, pinning to the taskbar is supposed to be user-only. But Chrome circumvents that and pins anyways, actively avoiding user preference. (And they drop an icon on the desktop, without asking.)