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 >
