[Full-Disclosure] Fwd: IObjectSafety and Internet Explorer

From: Georgi Guninski (guninski_at_guninski.com)
Date: 03/03/05

  • Next message: ren hoek: "Re: [Full-Disclosure] PIVX IS BANKRUPT"
    Date: Thu, 3 Mar 2005 12:06:01 +0200
    To: full-disclosure@lists.netsys.com

    tru$tworthy computing in action.

    ----- Forwarded message from Shane Hird <shanehird@yahoo.com> -----

    Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm
    Precedence: bulk
    List-Id: <bugtraq.list-id.securityfocus.com>
    List-Post: <mailto:bugtraq@securityfocus.com>
    List-Help: <mailto:bugtraq-help@securityfocus.com>
    List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com>
    List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
    Delivered-To: mailing list bugtraq@securityfocus.com
    Delivered-To: moderator for bugtraq@securityfocus.com
    Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
    DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
      s=s1024; d=yahoo.com;
      b=UHlx/DCPay5aDx3sQLhz8ksQD4C3uPVxYXp0ZbQBw9VYpP5qoK2Fkukp3B328ifM0GilOTUGDfuJjT+rNuEQ3PJ5Hdm0A2VQAuM3E5WFqWRzOfWeBX63BJUZVsajfP3uICmK08t2MwA87Lud3oP/xH7KimUc7fmXC1WoQ4/vhv8= ;
    Date: Tue, 1 Mar 2005 06:59:35 -0800 (PST)
    From: Shane Hird <shanehird@yahoo.com>
    Subject: IObjectSafety and Internet Explorer
    To: bugtraq@securityfocus.com


    Problems with ActiveX in Internet Explorer are nothing new. However, I
    believe there is a design flaw in the way they are implemented in IE which
    could be easily corrected, but has never been addressed.

    The following issues with the use of IObjectSafety in Internet Explorer can
    be summed up with this excerpt from a Microsoft knowledge base article (PSS
    ID Number: 216434)

    INFO: How Internet Explorer Determines If ActiveX Controls Are Safe
    http://support.microsoft.com/kb/q216434/ :

    "There are two ways to mark a control as safe for scripting and
    Implement the IObjectSafety interface.
    Provide the following registry keys for the control's CLSID under the
    Implemented Categories section:
    The following key marks the control safe for scripting:
    The following key marks the control safe for initialization from persistent

    Microsoft recommends that you implement IObjectSafety to mark a control as
    safe or unsafe. This prevents other users from repackaging your control and
    marking it as safe when it is not.

    1] The IObjectSafety interface allows a container to retrieve the control's
    initialization and scripting capabilities through its
    SetInterfaceSafetyOptions method. First, Internet Explorer checks to see if
    a control implements the IObjectSafety interface. If it does, Internet
    Explorer calls SetInterfaceSafetyOptions for the IPersist interfaces to
    check if the object is safe for initialization. When a control is first
    scripted, Internet Explorer first calls SetInterfaceSafetyOptions on the
    IDispatchEx interface of the control. If that fails, it calls
    SetInterfaceSafetyOptions on the IDispatch interface.


    2] If the control does not implement the IObjectSafety interface, Internet
    Explorer looks under the Implemented Categories section of the control for
    the keys mentioned above. If these keys are not present, Internet Explorer
    warns the user according to the security settings."

    --------------------Design flaw

    What this article fails to mention is that "checks to see if a control
    implements the IObjectSafety interface" requires and results in the starting
    of the COM server process. This is due to the requirement of COM that
    querying for an interface is done thorough the servers running code, rather
    than a static lookup for the interface.

    This means that, even if the COM server has not been marked as safe, or was
    even built before the existence of Internet Explorer, it can still be
    started (at least to the point where IObjectSafety can be queried) by
    arbitrary web pages on the Internet. (with the default IE "Medium" security

    AFAIK, this is also relates to why there was the spate of {1111-1111-11..}
    codebase=calc.exe type exploits possible in IE.

    This poses two problems:

    ---<1) We have no easy way of determining what COM servers on a given
    machine can be started and scripted by IE.

    Enumerating safe objects using the registry keys is both fast and stable.
    But with the addition of objects which can only be determined if they are
    safe by starting the (potentially heavyweight) COM server and querying
    them, this becomes impractical to do.

    ---<2) Any COM server can be started, including potentially corrupt or
    dangerous servers, that were never marked as safe.

    Just starting the server and querying for IObjectSafety in 99% of cases
    isn't going to cause any significant security violation. However this is
    dependent on the particular components installed on the machine and how they
    initialise. Components that may never have been intended to be started from
    remote web pages. It also poses a stability issue for IE.

    --------------------Exploitable "safe" objects

    To give an example of a control which has "IObjectSafety" but not marked as
    safe by keys in the registry, we have the Log Sink class provided by
    pkmcore.dll (Common Files/Microsoft Shared/Web Folders/).

    This object would allow a remote attacker to write data to any file. I.e..

    <object id=ctl
    <script language="vbscript">
    ctl.initsink "C:\autoexec.bat"
    ctl.addstring "echo Drive formatted? ", ""

    After discovering this object, a search through Microsoft's security
    bulletins revealed nothing, however the support database revealed this

    One 128mb patch later for a product I never installed (I believe it is
    installed as a part of Office 2003), and the file is updated to no longer
    allow log file creation by remote sites. (Although a recent service pack for
    Office 2003 also claims to update the file to the same corrected version).

    Regardless of the current exploitability of this object, it illustrates the
    point that potentially insecure components can lay dormant on a machine,
    with no easy way of determining whether IE will make use of them or not.

    --------------------IObjectSafety Enumeration

    I have written some very rough code to check for COM servers which implement
    the IObjectSafety interface. There is also code for "fuzzing" the IDispatch
    interface of the components, as well as any IDispatch interfaces returned
    from the methods, by calling every method with garbage values, or overly
    long BSTRs.

    This is by no means production code, but it serves its purpose:

    There is also a modified tscon32 sample which helps to fuzz objects which
    expect an OLE host.

    These programs try to "emulate" Internet Explorer with its ActiveX hosting,
    by following the steps outlined in the knowledge base article above. If a
    COM server crashes or formats your drive while using these programs,
    theoretically it would have also been possible from a remote web page. The
    exceptions are: it ignores 'Kill bits', doesn't correctly do the OLE
    'stuff', and still treats a control as safe if IObjectSafety returns
    "unsafe" but the registry marks otherwise (uncommon).

    Its interesting to note that after running these tools, there are often many
    processes left hanging and general misbehaviour. It is generally best to
    reboot after running it. Having said that, there is nothing stopping a web
    page from doing the exact same thing as it works in the same way that IE

    Using this code, I have uncovered the following objects that will crash or
    otherwise render unusable the Internet Explorer process when hosted on a web
    page. They are all possible without any user interaction or lowering of
    security settings.

    To generate that list, I simply ran axenum which ran through and tried to
    instantiate each component on my machine. When an exception occurred, it
    outputted the CLSID of the component. I then took each CLSID and created a
    web page and visited it remotely using IE, and logged which ones crashed IE.

    There were a lot more components that generated exceptions, however didn't
    when hosted in IE. I assume this is because the initialisation code makes
    certain assumptions about its host, which can cause a crash when hosted
    under something that isn't OLE aware for example, but work fine when they

    **** {0006F071-0000-0000-C000-000000000046}
    **** Outlook Progress Ctl

    **** {0CF32AA1-7571-11D0-93C4-00AA00A3DDEA}
    **** System Monitor Source Properties

    **** {1AA06BA1-0E88-11d1-8391-00C04FBD7C09}
    **** CLSID_CCommAcctImport

    **** {233A9694-667E-11d1-9DFB-006097D50408}
    **** Outlook Express Address Book

    **** {283807B8-2C60-11D0-A31D-00AA00B92C03}
    **** Danim

    **** {2c10a98f-d64f-43b4-bed6-dd0e1bf2074c}
    **** Microsoft Visual Database Tools Query Designer V7.0

    **** {3050f667-98b5-11cf-bb82-00aa00bdce0b}
    **** Microsoft Html Popup Window

    **** {549B5CC4-4A86-11D7-A4DF-000874180BB3}
    **** SmartConnect Class

    **** {8E26BFC1-AFD6-11CF-BFFC-00AA003CFDFC}
    **** Helper Object for Java

    **** {8EE42293-C315-11D0-8D6F-00A0C9A06E1F}
    **** CLSID_ApprenticeICW

    **** {8FE7E181-BB96-11D2-A1CB-00609778EA66}
    **** Microsoft MS Audio Decompressor Control Property page

    **** {ABBA001B-3075-11D6-88A4-00B0D0200F88}
    **** OpenCable Class

    **** {CE292861-FC88-11D0-9E69-00C04FD7C15B}
    **** VideoPort Object

    **** {F0975AFE-5C7F-11D2-8B74-00104B2AFB41}
    **** WMI ADSI Extension

    //Im not too sure uuidgen was used here...
    **** {CAFEEFAC-0014-0002-0003-ABCDEFFEDCBA}
    **** Java Plug-in 1.4.2_03

    **** {CAFEEFAC-0014-0002-0003-ABCDEFFEDCBB}
    **** Java Plug-in 1.4.2_03 <applet> redirector

    **** {CAFEEFAC-0014-0002-0004-ABCDEFFEDCBA}
    **** Java Plug-in 1.4.2_04

    **** {CAFEEFAC-0014-0002-0004-ABCDEFFEDCBB}
    **** Java Plug-in 1.4.2_04 <applet> redirector

    Interestingly, most of these problems cannot be reproduced by opening the
    page in the 'local zone', as Internet Explorer blocks the object with the
    "yellow information bar". Yet, IE does not do this when viewing the page in
    the Internet Zone. Also, "Maxthon", an MSHTML host which effectively acts as
    a different chrome to Internet Explorer, did not appear to be vulnerable to
    many of the above list either.


    With IE7 in the works, perhaps Microsoft could take the following suggestion
    into consideration:

    To determine if an ActiveX control is safe:

    1) First check the registry for the "safe keys".
    1.1) If the key exists, query IObjectSafety and proceed as usual.

    1.2) If the key doesn't exist, ideally IE should proceed no further.

    But some objects may have been installed which don't set these keys and
    assume the IObjectSafety call. For compatibility, if the key doesn't exist,
    ask the user if they want to try add it as a usable add on (yellow
    information bar can be used).

    2) If the user agrees, and it passes the IObjectSaftey check, add the "safe"
    category keys to the registry for that component. Otherwise fail with no
    option to override - depending on security settings.

    With this system in place, it becomes a lot easier to enumerate all COM
    objects on the system with this key set and therefore 'startable' by IE.
    IE should show all components marked as safe in the manage add ons screen
    ("safe" objects on a system, effectively are IE add-ons, I believe the user
    should be made aware of them). This screen should have the ability to remove
    the 'safe' keys, and set kill bits for components that automatically re-add
    the keys or you don't want to be prompted about.
    This can all be done via the 'information bar' with no annoying prompts to
    the user. There would effectively be no perceivable difference to the end
    user other than a safer browsing experience.
    I can think of few reasons why MS chose to query IObjectSafety first. The
    only reason I can think of is querying objects with no local registry
    information, perhaps remote or recently installed? Regardless, the proposed
    system would still work with such objects, you would simply be prompted
    about the objects first use, and have the ability to revoke the permission
    at a later date.
    --------------------"Work around"
    You can use the "Administrator approved" option for ActiveX controls and the
    policy editor to achieve a similar effect. However, it requires manually
    inputting safe controls rather than making use of the already "safe"
    category keys available from ActiveX controls.
    --------------------Vendor Response
    That's a feature not a bug.
    Or to quote:
    "COM objects can be called from an object tag and if they are not actually
    ActiveX controls they can cause IE to terminate."
    Shane Hird.
    Do you Yahoo!? 
    Yahoo! Mail - now with 250MB free storage. Learn more.
    ----- End forwarded message -----
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html

  • Next message: ren hoek: "Re: [Full-Disclosure] PIVX IS BANKRUPT"