Microsoft Internet Explorer 10 MSHTML CElement::GetPlainTextInScope Out-Of-Bounds Read
Posted on 05 November 2016
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 http://blog.skylined.nl/20161103001.html. There you can find a repro that triggered this issue in addition to the information below. Follow me on http://twitter.com/berendjanwever for daily browser bugs. MSIE 10 MSHTML CElement::GetPlainTextInScope out-of-bounds read =============================================================== (The fix and CVE number for this bug are not known) Synopsis -------- 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. Description ----------- My fuzzers were using a predecessor of BugId (https://github.com/SkyLined/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 point? * `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. Exploit ------- 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. Cheers, SkyLined Repro: ?xm?> <!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">.VVVVVqqq<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;http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">&#<svg&; version="1.1"
 xmlns="http://www.w3.org/2000/svg">&#</svg>
"></option></var></head><body></link><track class="class_5" hreflang onwaiting='sssssssssssssssssssssssssssssss<______________)))))))))))))))))SSSSSS'>88888888888vv(GGGGGGGGSSSSSSSSSSSSSSSSSSSSSSSSSS,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,lllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllPeeeVVVVVVVVVVVVVVVVVVVVVVV5555555555599999ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc<dfn><hgroup><noframes indeterminate="M" nowrap=

Ldraggable=FireBrick action=YYYYYYYYYYYYYYTTTKKKKKKKKKKKKKKKQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ...>JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ:::::::::::::::::::::::::::::???????????????????????????????????OOOOOOOOOOOOOOOOOOOOOOOO
