full-disclosure - MSIE (mshtml.dll) OBJECT tag vulnerability revealed

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Thu May  4 05:43:37 2006
From: mephistodreaming at hush.com (mephistodreaming@...h.com)
Subject: MSIE (mshtml.dll) OBJECT tag vulnerability
	revealed

Greetings Full Disclosure.

I am surprised that nobody has yet understood the Internet Explorer 
vulnerability, to the extent that at last I have arrived upon the 
decision to impart my knowledge. The next paragraphs will describe 
the vulnerability in full. N. B. These facts have been known in 
subtler circles from the beginning.

All have witnessed the NULL dereference but this has been the 
extent of investigation to this day. The condition is caused in 
CStyleSheet::ChangeStatus by lacking a check of the return status 
of CStyleSheetArray::AddStyleSheet inside CStyleElement::Notify. As 
such, a CStyleSheet is provided to CStyleSheet::ChangeStatus 
wherein the pointer at CStyleSheet+0x28 retains NULL. This is 
caused by a restriction inherent within 
CStyleSheetArray::AddStyleSheet whereby an excess of 31 
CStyleSheets are added to a CStyleSheetArray. The importance of 
OBJECT tags is minor but here it causes CStyleSheets in excess of 
31 (corresponding to STYLE tags nested within an OBJECT) to be 
added and fail. Doubtlessly the intrepid reader will become aware 
of tags besides OBJECT that produce likewise behaviour.

Exploitation ensues when the NULL pointer is accessed within the 
confines of exception handling. High in the lofty call stack 
CElement::Inject has instantiated a class instance of 
CMarkupPointer that will become conjoined to the document state 
preceeding the NULL pointer. Higher still is the exception handler 
to which the stack will regress upon the fault. As such, this 
CMarkupPointer becomes then undefined, however it will be used 
again (by CMarkupPointer::SetMarkup) after it is awash in the data 
of later procedure calls that come and have gone. I leave it as an 
exercise to the reader to achieve exception handling. One has 
mentioned the Explorer process and therein he is correct though be 
it a lesser example. The capable reader too can reliably expose a 
data borne vector of instilling the memory of the eradicated 
CMarkupPointer.

More knowledge will proceed if nobody proves fit to bear the torch.
-MD

Concerned about your privacy? Instantly send FREE secure email, no account required
http://www.hushmail.com/send?l=480

Get the best prices on SSL certificates from Hushmail
https://www.hushssl.com?l=485