204894 - Implement GeckoActiveXObject.supports(clsid)

Status: VERIFIED FIXED

(Core :: XPConnect, defect)

Description

[Adam Lock]

Implement a method / parameterized property on GeckoActivex that allows JS to
determine whether a control is supported in Mozilla.

For example,

if (GeckoActiveXObject.supports("814ba433-a816-4785-9f95-ad3ba0a43dab")
  document.write("<object> etc.");
else
  alert("Boo hoo no support for my object!");

Note that making this take a useful form while respecting privacy / security
issues might be problematic.

For example, supports(clsid) should certainly not say whether the control is
installed (otherwise someone could probe every clsid on the system), but just
whether the current policy allows that control to be instantiated assuming it
were installed.

Also, the method should not supports progids, since the impl would have to look
up the progid in the registry to determine the clsid. A clever attacker could
probe for progids and still perhaps figure out what is installed and what is not
based the answers returned.

For example, if "Foo.SomeObject.1" maps to
"814ba433-a816-4785-9f95-ad3ba0a43dab", an attacker could call
GeckoActiveX.supports("Foo.SomeObject.1") and
GeckoActiveX.supports("814ba433-a816-4785-9f95-ad3ba0a43dab"). If the first call
failed but the second succeeded I would know that "Foo.SomeObject.1" is not
installed because the progId lookup failed, but the clsid lookup succeeded,
meaning the current policy allows it so its not because of that.

Comment 1

[David Bradley]

Good points Adam, I hadn't thought about the prog id and class id testing trick.
I wonder if that's going to be a problem for anyone? We support instantiating
via a prog id. Only allowing this check via class ID seems a little odd, but
maybe that's the price of security.

Comment 2

[Phil Schwartau]

I came across the following syntax at http://platinum.yahoo.com, where
the site determines whether the client supports Windows Media Player 9:

   <span style="behavior:url(#default#clientCaps)" id="cc"></span> 

   <script language=JavaScript> 
   var cv = cc.getComponentVersion("{6BF52A52-394A-11D3-B153-00C04F79FAA6}",  
                                   "componentid"); 

   if (cv == null || cv == "") 
     top.location.href = "http://platinum.yahoo.com/agentcheck.html"; 
   </script>


(The clsid is for Windows Media Player 9). Notice the <span>
element acquired the getComponentVersion() method via CSS !!!

      style="behavior:url(#default#clientCaps)"

Adam found references for this syntax, which at present 
is IE-only, and is known as "DHTML Default Behaviours":

  http://msdn.microsoft.com/workshop/author/behaviors/overview.asp
  http://msdn.microsoft.com/workshop/author/behaviors/howto/using.asp

As this is not currently supported by Mozilla, it's another of
the peripheral changes that Yahoo, for example, would have to make
in order for Mozilla to handle http://platinum.yahoo.com.

Comment 3

[David Bradley]

Thought I had already targetted this, ->1.5a

Comment 4

[David Bradley]

I've been waffling on whether supports should ask the object whether it is safe
for scripting. Initially I really didn't want supports to instantiate the
object, but that would mean that the results for supports and
GeckActiveXObject("xxx") would be different and that didn't seem good either.

So I'm looking for some feed back on what others think is the appropriate approach.

Comment 5

[Heikki Toivonen (remove -bugzilla when emailing directly)]

If you instantiate the object, and it is hostile, it could cause havoc at that
point. Of course, if the object was hostile the installation probably would have
caused harm as well.

Comment 6

[Adam Lock]

Here is some info about the methods that the clientCaps behaviour exposes on any
element given that style

http://msdn.microsoft.com/workshop/author/behaviors/reference/methods/getcomponentversion.asp
http://msdn.microsoft.com/workshop/author/behaviors/reference/methods/iscomponentinstalled.asp

Importantly, the documentation says that only certain clsids are detectable
using these methods.

http://msdn.microsoft.com/workshop/author/behaviors/reference/methods/detectable.asp

This suggests that other clsids are prevented deliberately to prevent 'sniffing'
a big long list to see what might be on the machine.

Perhaps we need to restrict ourselves in the same way, using the whitelist
perhaps, or a hardcoded list in blacklist mode. IE might even store these
'detectable' clsids somewhere in the registry where they can be read.

Comment 7

[Adam Lock]

Attachment: Sample clientCaps

I grabbed this from the web. Load it in IE.

I'm fairly sure that clientCaps will only report back on CLSIDs that it finds
in 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components

and possibly under HKEY_CURRENT_USER too.

Comment 8

[David Bradley]

Heikki, yes that was my concern as well. And I was trying to weigh that against
parity between GeckoActiveXObject("xxx") and GeckoActiveXObject.supports("xxx");
But the instantiation is only the last part, and only occurs if all the other
checks succeed. It also makes supports a heavier function to call as well.

Adam, I wonder, will IE instantiate a component if it's not in Installed Components?

By default ActiveX/COM objects create an entry here (at least the ones I built).
But maybe that's a reasonable requirement for controls being used on the web.
So, should an item on the white list that isn't in this list be disallowed?

I found the following link:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gp/774.asp but
I'm unable to figure out how it works on XP.

Comment 9

[Adam Lock]

In DevStudio 6 at least, controls do not create an entry in this list yet they
work fine in IE without warnings when they implement IObjectSafety. So I don't
believe there is a requirement that they appear here. Not being here might mean
they cannot be detected but they can still be instantiated. Other controls, for
example the Shutterfly control also do not appear here but work fine in IE.

The dumb thing about this list is that it contains stuff which should not be
detectable (you would think), such as CLSIDs for various service pack fixes. If
restricting the list of CLSIDs is meant to be a security thing, it would seem
counterproductive to let a page see what service packs I have applied. I
verified that I can see them by modifiying the sample page. But ask it about
Shutterfly and it returns nothing. 

I also tried to figure out what the second sIDType parameter on
isComponentInstalled / getComponentVersion is meant to represent. If you pass
'componentId' the docs hint that my assumption of where it is checking is
correct (Active Setup). If I just pass in 'clsid' instead, it returns version
information but only for the WMP and not the other examples in the test page. I
do not know if 'clsid' is a valid arg since the docs are vague, but perhaps it
falls back on a hardcoded list when the type is a clsid.

Comment 10

[David Bradley]

Well, I searched around a bit, unfortunately accidentally shutdown the browser
and lost my original comment here along with the various links. So I'll summarize.

Some nsIDTypes: http://www.allfreetech.com/ShowMain.asp?MainID=81

Looks like isComponentInstalled takes clsid, ComponentID, progID, mime(not sure
of the exact spelling). Also, apparently there's a VBScript isComponentInstalled
that returns 0, 1, 2, or 3. denoting if it's installed, a newer version, or the
user said don't check. As opposed to true/false of the DHMTL version.

Given there is little documentation on this, I think it would probably be best
to avoid it for now. It's really probably only useful in black list mode anyway.

Given that some embedders might want to use such vendor specific checks or
something completely different. I wonder if it would be better to provide an
interface to allow vendors to replace our current default vendor specific checks
with their own?

Comment 11

[David Bradley]

Attachment: Addes GeckoActiveXObject.supports

Ok, this doesn't support the DHTML behaviors. I just don't think that's
documented well enough for us to get it close to right. So I'd rather avoid it
till it's more well known. We could always add a isComponentInstalled to
GeckoActiveXObject if and when that happens.

I also chose not to ask the object if it's safe when using
GeckoActiveXObject.supports. This sacrifices parity between
GeckoActiveXObject() and GeckoActiveXObject.supports(), but makes it a much
lighter weight function that if it had to instantiate, ask, and then throw away
the object.

If anyone can make a strong argument for either of these two issue, I'm open.

Comment 12

[David Bradley]

Comment on attachment 125596 [details] [diff] [review]
Addes GeckoActiveXObject.supports

Looking for reviews

Comment 13

[Adam Lock]

I'll review in a moment, but first we definitely don't want to create an object
ever just to determine if its safe or not. Creating an Adobe Acrobat, MS Word
document, or even an IE browser object is obviously wasteful.

This functionality has to compare the clsid to *some* list and possibly
additionally say whether its installed or not.

The list could be a combination of:

1. Whitelist / blacklist
2. Hardcoded list of clsids
3. Some part of the registry

And then finally if it passes whatever of these we test, possibly test if the
clsid is even installed. This last step is not acceptable from a
security/privacy standpoint if we only test the whitelist/blacklist and its in
blacklist mode. And saying we support it is provisional on its object safety and
further checks when its actually created.

Perhaps the answer for the moment, is supports() does not say whether the
control is actually installed or not, just whether Moz would support it if it
were (and we're not going to say if it is) and if passes the safe for scripting
checks if they're enabled.

If later we want to add an isComponentInstalled / getComponentVersion, it can
supplement the existing supports behaviour. Personally I think that this would
be sufficient for now. And if we add an isComponentInstalled, it can use the
hardcoded list that MS documents as an additional filter.

Comment 14

[Adam Lock]

Comment on attachment 125596 [details] [diff] [review]
Addes GeckoActiveXObject.supports

r=adamlock

This implementation seems to make the most sense for now.

Comment 15

[Alec Flett]

Comment on attachment 125596 [details] [diff] [review]
Addes GeckoActiveXObject.supports

sr=alecf

Comment 16

[David Bradley]

Patch checked into trunk. Leaving open for possible consideration of the 1.4
branch later.

Comment 17

[Henrik Gemal]

FYI: I've added GeckoActiveX detection to BrowserSpy
http://gemal.dk/browserspy/activex.html

Comment 18

[David Bradley]

Closing to get off 1.5a radar, though these should still be checked into 1.4 branch.

Comment 19

[Phil Schwartau]

Rubber-stamp vrfy