lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon Apr 24 00:55:22 2006 From: ben.lambrey at pandora.be (Ben Lambrey) Subject: MSIE (mshtml.dll) OBJECT tag vulnerability On Sunday 23 April 2006 01:30, Michal Zalewski wrote: > Perhaps not surprisingly, there appears to be a vulnerability in how > Microsoft Internet Explorer handles (or fails to handle) certain > combinations of nested OBJECT tags. This was tested with MSIE > 6.0.2900.2180.xpsp.040806-1825 and mshtml.dll 6.00.2900.2873 > xpsp_sp2_gdr.060322-1613. > > At first sight, this vulnerability may offer a remote compromise vector, > although not necessarily a reliable one. The error is convoluted and > difficult to debug in absence of sources; as such, I cannot offer a > definitive attack scenario, nor rule out that my initial diagnosis will be > proved wrong [*]. As such, panic, but only slightly. > > Probably the easiest way to trigger the problem is as follows: > > perl -e '{print "<STYLE></STYLE>\n<OBJECT>\nBork\n"x32}' >test.html > > ...this will (usually) cause a NULL pointer + fixed offset (eax+0x28) > dereference in mshtml.dll, the pointer being read from allocated but still > zeroed memory region. > > The aforementioned condition is not exploitable, but padding the page with > preceeding OBJECT tag (and other tags), increasing the number of nested > OBJECTs, and most importantly, adding bogus 'type=' parameters of various > length to the final sequence of OBJECTs, will cause that dereference to > become non-NULL on many installations; then, a range of other interesting > faults should ensue, including dereferences of variable bogus addresses > close to stack, or crashes later on, when the page is reloaded or closed. > > [ In absence of sources, I do not understand the precise underlying > mechanics of the bug, and I am not inclined to spend hours with a > debugger to find out. I'm simply judging by the symptoms, but these > seem to be indicative of an exploitable flaw. ] > > Several examples of pages that cause distinct faults in my setup (your > mileage may and probably WILL vary; on three test machines, this worked as > described; on one, all examples behaved in non-exploitable 0x28 way): > > http://lcamtuf.coredump.cx/iedie2-1.html (eax=0x0, instant dereference) > http://lcamtuf.coredump.cx/iedie2-2.html (bogus esi on reload/leave) > http://lcamtuf.coredump.cx/iedie2-3.html (page fault on browser close) > http://lcamtuf.coredump.cx/iedie2-4.html (bogus esi on reload/leave) > > Well, that's it. Feel free to research this further. This vulnerability, > as requested by customers, is released in strict observance of the Patch > Wednesday & Bug Saturday policy. IE 6 on Windows 2003+SP1 also crashes. IE version: 6.0.3790.1830 mshtml.dll version 6.0.3790.2666
Powered by blists - more mailing lists