Closed Bug 503451 (CVE-2009-3987) Opened 12 years ago Closed 12 years ago
Active XObject exception messages can be used to enumerate installed COM objects
2.36 KB, text/html
11.66 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:188.8.131.52) Gecko/2009060214 Firefox/3.0.11 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206pre) 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
Brief example demonstrating how COM objects can be enumerated based on exception message differences.
Component: General → XPConnect
Product: Firefox → Core
QA Contact: general → xpconnect
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.
Comment on attachment 397109 [details] [diff] [review] Remove GeckoActiveXObject and similar unnecessary globals, rev. 1 Can I give more than 1 r+?
Attachment #397109 - Flags: review?(mrbkap) → review+
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 :-)
Attachment #397109 - Flags: superreview?(jst) → superreview+
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment on attachment 397109 [details] [diff] [review] Remove GeckoActiveXObject and similar unnecessary globals, rev. 1 Approved for 220.127.116.11 and 18.104.22.168, a=dveditz for release-drivers
jst: this needs a 1.9.2 branch approval
Attachment #397109 - Flags: approval1.9.2? → approval1.9.2+
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 22.214.171.124 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199pre) Gecko/2009111921 GranParadiso/3.0.16pre (.NET CLR 3.5.30729).
You need to log in before you can comment on or make changes to this bug.