This is a friendly warning that your web-browser does not currently protecting your privacy and/or security as
well as you might want. Click on this message to see more information about the issue(s) that were detected.
November 3rd, 2016
MSIE 10 MSHTML CElement::
(The fix and CVE number for this bug are not known)
A specially crafted web-page can cause Microsoft Internet Explorer 10 to read data out-of-bounds. This issue was fixed before I was able to analyze it in detail, hence I did not determine exactly what the root cause was.
Internet Explorer 10
An attacker would need to get a target user to open a specially crafted web-page. No special configuration settings are required in order to trigger the issue. No realistic mitigations are known; Javascript is not required to trigger the issue.
While my fuzzing framework does reduce the size of the repro for every case it finds, this unfortunately does not yet produce the very tiny, straight-forward repro files you may have come to expect from me. In order to create these, I need to manually clean up what my fuzzers produced. In this case, because the issue was addressed my Microsoft before I was able to look at the bug, I did not go trough that step, so the only repro I have is a bit of a mess, does not clearly provide information on what triggers the issue and probably contains a lot of data that is not actually needed to trigger it at all.
Repro.My fuzzers were using a predecessor of BugId to generate a report whenever they found a bug. Unfortunately, this wasn't as sophisticated as BugId is, so the information contained in these report is not as helpful. Still, I saved three reports, for crashes with slightly different stacks. This could have been caused by three different versions of MSIE 10 (every month when Microsoft released a new version with patches, the code may be optimized differently, which could explain these differences). It could also have been caused by the fuzzing framework attempting to reduce the size of the repro by cutting out chunks, which could lead to slightly different code-paths. Unfortunately, I do not know which.
Either way, looking at the reports that were automatically generated for this bug (which can be found at the end of this article), one can find the following interesting information on all three:
CTextArea::, which
suggests the one textarea element found in the repro is important to
triggering the issue.CElement::, which is commonly used to extract the
text inside an element, so the text content in the textarea element is
probably also important to triggering the issue. Since there is no closing
</textarea> tag, this could be all the data in the repro after the opening
<textarea ...> tag, or up to the first closing tag (</div>), depending
on how the HTML parser works.Clicking on stack Frame 1 in the report shows the report contains some
disassembly and registers. Unfortunately, the code that generated the
disassembly had a bug and started at the wrong address, so this isn't very
useful. However, clicking on Registers will show that:
MSHTML!memcpyedx.The Registers section also suggest the following:
ecx was 0, so maybe all the data was already copied at this point?edx was apparently used as a pointer to the data being copied.On-line documentation for memcpy does not mention this behavior of looking
for a linefeed, so it could be that MSHTML has an odd implementation, or that
the symbol is simply wrong. I'm assuming that the code did copy the text
content of a textarea element and was looking for a CR, LF line
terminator. Unfortunately, the data at edx only contained one or the other,
causing the code to look for the LF outside of the memory area allocated to
store the data.
The above suggests that there is limit opportunity for exploiting this issue:
it may be possible to determine if a memory block allocated for a string of an
attacker controlled size is followed by a memory block that starts with the
bytes 0A 00. To better understand the impact, one would have to get an older
version of MSIE 10 and debug the crash. Unfortunately, I did not have time to
do so.
This report was generated using a predecessor of BugId, a Python script created to detect, analyze and id application bugs. Don't waste time manually analyzing issues and writing reports but try BugId out yourself today! You'll get even better reports than this one with the current version. BugId report: MSHTML.id: MSHTML.dll!CElement:: GetPlainTextInScope Arbitrary~000 AVR(02058506) description: Security: Attempt to read from unallocated arbitrary memory (@0x0D863000) in MSHTML. dll!CElement:: GetPlainTextInScope note: Based on this information, this is expected to be a security issue!
This report was generated using a predecessor of BugId, a Python script created to detect, analyze and id application bugs. Don't waste time manually analyzing issues and writing reports but try BugId out yourself today! You'll get even better reports than this one with the current version. BugId report: MSHTML.id: MSHTML.dll!CElement:: GetPlainTextInScope Arbitrary~000 AVR(4B67A6C4) description: Security: Attempt to read from unallocated arbitrary memory (@0x10680000) in MSHTML. dll!CElement:: GetPlainTextInScope note: Based on this information, this is expected to be a security issue!
This report was generated using a predecessor of BugId, a Python script created to detect, analyze and id application bugs. Don't waste time manually analyzing issues and writing reports but try BugId out yourself today! You'll get even better reports than this one with the current version.id: MSHTML.dll!CElement:: GetPlainTextInScope Arbitrary~000 AVR(56BB30E2) description: Security: Attempt to read from unallocated arbitrary memory (@0x119A6000) in MSHTML. dll!CElement:: GetPlainTextInScope note: Based on this information, this is expected to be a security issue!
This work is licensed under a Creative Commons Attribution-Non‑Commercial 4.