MSIE (mshtml.dll) OBJECT tag vulnerability

2006.04.26
Risk: High
Local: Yes
Remote: Yes
CWE: CWE-399


CVSS Base Score: 2.6/10
Impact Subscore: 2.9/10
Exploitability Subscore: 4.9/10
Exploit range: Remote
Attack complexity: High
Authentication: No required
Confidentiality impact: None
Integrity impact: None
Availability impact: Partial

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>nBorkn"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. [*] The ability of the attacker to document the attack scenario probably doesn't matter for those who pretend to care; cryptic "hi" to Secunia and their standards of conduct.


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2019, cxsecurity.com

 

Back to Top