Bugzilla@Mozilla – Bug 503451
GeckoActiveXObject exception messages can be used to enumerate installed COM objects
Last modified: 2010-03-08 11:46:43 PST
Summon comment box
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.0.11) Gecko/2009060214 Firefox/3.0.11 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1pre) Gecko/20090708 Shiretoko/3.5.1pre The exception messages from GeckoActiveXObject differ based on whether the requested COM object ProgID is present in the Windows registry. Exception messages: - COM object not installed: COM Error Result = 800401f3 - COM object installed: COM Error Result = 80004005 By creating an extensive list of ProgID's it would be possible to profile a user. Some software installs different ProgID's based on version, so specific version detection is also possible. This behavior may lead to a loss of user privacy or allow for targeted exploitation. Reproducible: Always
Created attachment 387800 [details] example of COM object enumeration Brief example demonstrating how COM objects can be enumerated based on exception message differences.
Fun. bsmedberg, do you know this code, or know who does? I can't even find the code.
http://mxr.mozilla.org/mozilla-central/source/js/src/xpconnect/src/XPCIDispatchExtension.cpp#223 I think those bits can be safely completely removed.
Created attachment 397109 [details] [review] Remove GeckoActiveXObject and similar unnecessary globals, rev. 1
Comment on attachment 397109 [details] [review] Remove GeckoActiveXObject and similar unnecessary globals, rev. 1 Can I give more than 1 r+?
so um. before we go off removing stuff which was added by AOL, we could talk to the people who remember it. bsmedberg: you claim it isn't usable by content at all. Suppose content has universalxpconnect, is it still unusable? I'm not actively defending the feature (I remember it, and I think I understand its goals).
I do not think it is necessary to walk into the mists of time in order to remove features that are clearly not an important part of the web platform nor of our extension platform. We will be removing idispatch scripting altogether as soon as WinMo doesn't depend on it for the activex bridge.
The only issue that I know of around this outside of the obvious direct use is for browser sniffing. Supposedly some sites were using the presence to determine the browser. Obviously not the proper way to do it, but there were sites doing it. Hopefully they're gone now :-)
http://hg.mozilla.org/mozilla-central/rev/ee9ea7ed3c7a
Comment on attachment 397109 [details] [review] Remove GeckoActiveXObject and similar unnecessary globals, rev. 1 Approved for 1.9.1.5 and 1.9.0.16, a=dveditz for release-drivers
jst: this needs a 1.9.2 branch approval
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/e2c8fee94aff http://hg.mozilla.org/releases/mozilla-1.9.2/rev/b8ae3dc97cea
Checking in src/XPCDispPrivate.h; /cvsroot/mozilla/js/src/xpconnect/src/XPCDispPrivate.h,v <-- XPCDispPrivate.h new revision: 1.25; previous revision: 1.24 done Checking in src/XPCIDispatchExtension.cpp; /cvsroot/mozilla/js/src/xpconnect/src/XPCIDispatchExtension.cpp,v <-- XPCIDispatchExtension.cpp new revision: 1.24; previous revision: 1.23 done Checking in src/nsXPConnect.cpp; /cvsroot/mozilla/js/src/xpconnect/src/nsXPConnect.cpp,v <-- nsXPConnect.cpp new revision: 1.175; previous revision: 1.174 done Checking in src/xpcjsruntime.cpp; /cvsroot/mozilla/js/src/xpconnect/src/xpcjsruntime.cpp,v <-- xpcjsruntime.cpp new revision: 1.75; previous revision: 1.74 done Checking in src/xpcprivate.h; /cvsroot/mozilla/js/src/xpconnect/src/xpcprivate.h,v <-- xpcprivate.h new revision: 1.287; previous revision: 1.286 done
Verified for 1.9.0.16 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.16pre) Gecko/2009111921 GranParadiso/3.0.16pre (.NET CLR 3.5.30729).