MSIE clientCaps "isComponentInstalled" and "getComponentVersion" registry information leakage
Hello bugtraq,
Here is a verbatim copy of an email I sent to secure@xxxxxxxxxxxxx
on September 12th. 7 weeks later I am doubtful that a response is
forthcoming.
Today I re-tested against the latest version (6.0.2800.1106) of IE,
and also wrote an additional page allowing more arbitrary testing.
The arbitrary test page (requires javascript) is here:
http://mypage.direct.ca/s/schinke/defaultbehaviors/clientCapsChoose.html
Other than the addition of the above page, the message below is
exactly what was available to Microsoft.
A quick summary is that the documented limitson what components the
default behavior "clientCaps" will return results for aren't
enforced. Any component with information stored in the correct
location in the correct format can be queried via "clientCaps". Some
of the information disclosed is harmless. Some information disclosed
is disturbing, however. At the arbitrary test page above, win98
users can check the status of their 128 bit encryption patch by
typing "128PATCH" into the box and hitting enter or submit.
This is a forwarded message
From: Sam Schinke <sschinke@xxxxxxxxxxxxx>
To: secure@xxxxxxxxxxxxx, security@xxxxxxxxxxxxx
Date: Thursday, September 11, 2003, 5:50:53 PM
Subject: clientCaps "isComponentInstalled" and "getComponentVersion" registry
information leakage
===8<==============Original message text===============
Hello Microsoft,
While creating some pages to demonstrate the information that
Internet Explorer is able to return via scripting of the default
behavior "clientCaps" I found that the MSDN articles on the topic
understate what information clientCaps, and specifically the
"isComponentInstalled" and "getComponentVersion" methods are able to
disclose about the software installed on a PC visiting a webpage
with JScript/VBScript enabled.
clientCaps is described here:
http://msdn.microsoft.com/workshop/author/behaviors/reference/behaviors/clientcaps.asp
The "Component ID"'s that clientCaps is documented as capable of
disclosing information about via "isComponentInstalled" and
"getComponentVersion" is listed at the following location:
http://msdn.microsoft.com/workshop/author/behaviors/reference/methods/detectable.asp
"isComponentInstalled" is documented here:
http://msdn.microsoft.com/workshop/author/behaviors/reference/methods/iscomponentinstalled.asp
And "getComponentVersion" is documented here:
http://msdn.microsoft.com/workshop/author/behaviors/reference/methods/getcomponentversion.asp
The wisdom of disclosing the above information aside, there is
additional information that clientCaps discloses.
Specifically, I found that "isComponentInstalled" and
"getComponentVersion" would return information meeting the following
criteria beyond the information contained in the "Detectable
Components" documentation:
1) A registry key matching the value given in the "sID" parameter to
either method exists at the following location:
HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components
Note, this parameter need not be in the form of a GUID. Any string
will do.
2) The registry key matching the sID parameter contains two values
meeting the following criteria:
Value 1: A binary or DWORD value called "IsInstalled" with a value
of 1.
Value 2: A string value called "Version" formatted as follows:
"n,n,n,n" where each n is an integer. Different formats such as
"n.n.n.n" do not meet this criteria.
If these conditions are met, "isComponentInstalled" returns true and
"getComponentVersion" returns the "Version" string. This is in
direct contradiction of the documented behavior for these methods,
and does pose a security risk.
Some other keys/values are accessed when the relevant scripting
calls are made, however, they appear to have no bearing on whether
or not information is disclosed via clientCaps.
The result of this disclosure is that it becomes possible for a
scripted page to perform profiling of some of the installed software
and some of the patches on a machine (several patches seem to place
data in the registry that meets the criteria set above). This could
potentially lead to easier exploiting of machines vulnerable to
exploits that wouldn't otherwise be tried.
This could also lead to loss of privacy and a partial super-cookie.
Without a way to assess how similar these parts of people's
registries tend to be this isn't a certainty, however.
I also feel that the _documented_ disclosure by clientCaps is
excessive, but it is documented and apparently "by design" so I
mention my feeling only as "due dilligence". I have seen, however, a
virus variant that uses clientCaps to check if Microsoft's Virtual
Machine is installed before attempting to print an object tag that
would load an exploit.
My feeling is that the impact of this is "minimal" however I believe
that other areas where scripting can access any information from the
registry should be asessed for similar lack of documented
limitations on data disclosure.
I have created a page demonstrating the normal documented
functioning of clientCaps here:
http://mypage.direct.ca/s/schinke/defaultbehaviors/
And a page demonstrating some of this additional information leakage
here:
http://mypage.direct.ca/s/schinke/defaultbehaviors/clientCapsExtra.html
Also, exploitation of some of this leakage can be found in the wild,
though not by any malicious sites that I am aware of. The following
"browser spy" page reveals more information than is documented as
"detectable":
http://www.gemal.dk/browserspy/component.html
--
Best regards,
Sam mailto:sschinke@xxxxxxxxxxxxx
===8<===========End of original message text===========
--
Best regards,
Sam mailto:sschinke@xxxxxxxxxxxxx