Message-ID: <f9ea8fb7-c73f-0f27-26a8-33759f503d0b@nwever.nl>
Date: Thu, 3 Nov 2016 11:19:54 +0100
From: Berend-Jan Wever <berendj@...ver.nl>
To: fulldisclosure@...lists.org, Bugtraq <bugtraq@...urityfocus.com>
Subject: [FD] MSIE 10 MSHTML CElement::GetPlainTextInScope out-of-bounds read

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

Download attachment "0x2557C5AA.asc" of type "application/pgp-keys" (2035 bytes)


_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists