Message-ID: <1306807432.20031104203230@myrealbox.com>
Date: Tue, 4 Nov 2003 20:32:30 -0800
From: Sam Schinke <sschinke@...ealbox.com>
To: bugtraq@...urityfocus.com
Subject: MSIE clientCaps "isComponentInstalled" and "getComponentVersion" registry information leakage


Hello bugtraq,

  Here  is  a verbatim copy of an email I sent to secure@...rosoft.com
  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@...ealbox.com>
To: secure@...rosoft.com, security@...rosoft.com
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@...ealbox.com

===8<===========End of original message text===========  

-- 
Best regards,
 Sam                          mailto:sschinke@...ealbox.com

Powered by blists - more mailing lists