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

[Dave Ahmad <da () securityfocus com>]

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

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.

1. http://online.securityfocus.com/archive/1/298748
2. http://online.securityfocus.com/bid/5841
3. http://online.securityfocus.com/bid/3867

David Mirza Ahmad
Symantec

0x26005712
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
> http://www16.brinkster.com/liudieyu/BadParent/BadParent-MyPage.htm
> or
> clik.to/liudieyu ==> 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]
> clik.to/liudieyu ==> "How to contact Liu Die Yu" section