Re: (MSIE) when parent gives his son bad things ;) --"dialogArguments " again

From: Dave Ahmad (
Date: 11/19/02

  • Next message: NetBSD Security Officer: "NetBSD Security Advisory 2002-029: named(8) multiple denial of service and remote execution of code"
    Date: Tue, 19 Nov 2002 10:32:46 -0700 (MST)
    From: Dave Ahmad <>
    To: Liu Die Yu <>

    So. Yet another way to execute script code in the "My Computer"

    According to Microsoft (based on the response described in the Andreas
    Sandblad advisory [1]), the Sandblad method of executing commands with
    parameters employed in the "format C:" attack is not a vulnerability.
    Technically, they are correct -- the technique cannot be used by
    script that is not in the "My Computer" Zone. Unforunately the problem
    with that is that the Explorer access-control system is totally broken.
    Zone-based access control clearly cannot be relied upon. It is
    being demonstrated almost weekly that it is trivial for malicious content
    to cross Zones.

    So when Microsoft fixes the other zone-crossing vulnerability discovered
    by Liu Die Yu (technically, this would be a correct fix), the exploit can
    be quickly modified to use this vulnerability instead of the other --
    voila! you can format hard drives again, on patched systems. It's not
    just about formatting drives. Any command can be executed. Visit a
    website and you're done, right through the firewall.

    Without a doubt there are many more ways content can leak across
    Zones. It seems obvious that there is something fundamentally
    wrong with the way access control is implemented in Explorer. At what
    point are the controls being applied? How is it all represented in memory?
    How are credentials inherited/associated with objects? For example, if
    all that is required to bypass access controls on an object is accessing
    through a reference to it [2], something is very wrong with the whole thing.

    To be fair, what Microsoft is trying to do is very difficult. They have
    been responsive and take security seriously. Perhaps what can be
    done in the local zone should be limited in anticipation of future bugs
    such as this. For example, the simple "codebase" technique [3] can
    still be used to execute programs (without parameters) by code within
    the local zone. The Microsoft fix was to prevent this "feature" from
    being used in the Internet Zone (again, theoretically a correct fix).

    For end users what is the other option? To disable scripting? This is an
    unreasonable expectation for anyone who works with the Web or even uses it
    recreationally. Maybe it is time to sandbox browsers entirely.


    David Mirza Ahmad

    8D 9A B1 33 82 3D B3 D0 40 EB AB F0 1E 67 C6 1A 26 00 57 12

    On 19 Nov 2002, Liu Die Yu wrote:

    > IFRAME in a page opened by "openModalDialog" has "dialogArguments" of its
    > parent.
    > [tested]MSIEv6(CN version)
    > {IEXPLORE.EXE file version: 6.0.2600.0000}
    > {MSHTML.DLL file version: 6.00.2600.0000}
    > [demo]
    > at
    > or
    > ==> BadParent-MyPage section.
    > /*note: please tell me if "MSIE SP1" allows an internet page contains an
    > iframe with local content*/
    > [exp]
    > IFRAME in a page opened by "openModalDialog" has "dialogArguments" of its
    > parent. so Attacker can open (via "openModalDialog") his page which
    > contains an iframe whose content is in the victim zone and
    > uses "dialogArguments" directly without filtering.
    > in the demo:
    > (*)"victim zone" is localzone;
    > (*)the page from victim zone is "res://shdoclc.dll/privacypolicy.dlg"; it
    > uses "cookieUrl" without filtering.
    > [how]
    > realize that IFRAME has some properties the same as those of its parent.
    > but the parent can be bad.
    > (BTW, i used to hate that my parents give me many bad things, now i
    > realize it's my job to resist bad things. ;) )
    > [contact]
    > ==> "How to contact Liu Die Yu" section