what you don't know can hurt you

Microsoft Internet Explorer 11 iertutil LCIEGetTypedComponentFromThread Use-After-Free

Microsoft Internet Explorer 11 iertutil LCIEGetTypedComponentFromThread Use-After-Free
Posted Nov 19, 2016
Authored by SkyLined

A specially crafted web-page can cause the iertutil.dll module of Microsoft Internet Explorer 11 to free some memory while it still holds a reference to this memory. The module can be made to use this reference after the memory has been freed. Unlike many use-after-free bugs in MSIE, this issue, and apparently all code in this module, is not mitigated by MemGC. This issue appears to have been addressed in July 2016, as it failed to reproduce after the July security updates were installed.

tags | exploit, web
MD5 | 16a91c39281d3aa5ed25e13e1bf53a7d

Microsoft Internet Explorer 11 iertutil LCIEGetTypedComponentFromThread Use-After-Free

Change Mirror Download
Throughout November, I plan to release details on vulnerabilities I
found in web-browsers which I've not released before. This is the
thirteenth entry in that series. Unfortunately I won't be able to
publish everything within one month at the current rate, so I may
continue to publish these through December and January.

The below information is available in more detail on my blog at
http://blog.skylined.nl/20161117001.html.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

Microsoft Internet Explorer 11 iertutil LCIEGetTypedComponentFromThread
use-after-free
=======================================================================
(The fix and CVE number for this issue are unknown)

Synopsis
--------
A specially crafted web-page can cause the iertutil.dll module of
Microsoft Internet Explorer 11 to free some memory while it still holds
a reference to this memory. The module can be made to use this reference
after the memory has been freed. Unlike many use-after-free bugs in
MSIE, this issue, and apparently all code in this module, is not
mitigated by MemGC. This issue appears to have been addressed in July
2016, as it failed to reproduce after the July security updates were
installed.


Known affected software, attack vectors and mitigation
------------------------------------------------------
+ Microsoft Internet Explorer 11

An attacker would need to get a target user to open a specially
crafted web-page and allow the web-page to open a popup. The target
user may need to run MSIE in the non-default single process mode.
Disabling JavaScript should prevent an attacker from triggering the
vulnerable code path.

Description
-----------
This looks like a pretty straightforward use-after-free, but I did not
investigate at what point in the repro the memory gets freed and when it
gets re-used, so I do not know if an attacker has any chance to force
reallocation of the freed memory before reuse.

The issue can be triggered with MemGC enabled; the object that is freed
does not appear to be protected by MemGC.

The repro requires that MSIE is run in single-process mode in order to
trigger the use-after-free. It is not known if it is possible to tweak
the repro to have MSIE take a similar code-path that leads to a
use-after-free when MSIE is not in single-process mode.

MSIE can be started in single process mode by setting the following
registry key before starting MSIE:

`HKCU\Software\Microsoft\Internet Explorer\Main\TabProcGrowth = DWORD:0`

To revert this change, remove the registry key or set the value to 1 and
restart MSIE.

Exploit
-------
A number of factors appear to be getting in the way of creating a usable
exploit for this issue:
* I did not investigate if it is possible to reproduce the issue without
opening a pop-up to make it exploitable in the presence of a pop-up
blocker.
* I did not investigate if it is possible to reproduce the issue without
running MSIE in single-process process mode to exploit it on a system
with default settings.
* I did not investigate if it is possible to reallocate the freed memory
between the free and the use-after-free in order to modify control
flow.
Because there are so many things that would need to be investigated in
order to write an exploit, I felt it was not cost-effective for me to do so.

Time-line
---------
* July 2016: This vulnerability was found through fuzzing.
* July 2016: This vulnerability was submitted to ZDI and iDefense.
* July 2016: ZDI reports they are unable to reproduce the issue.
* November 2016: Details of this issue are released.

Cheers,
SkyLined



Repro.html

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=5">
<script>
onload = function () {
open("about:blank").close();
createAPopup();
document.write("x");
};
</script>
</head>
</html>


Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

June 2019

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jun 1st
    1 Files
  • 2
    Jun 2nd
    2 Files
  • 3
    Jun 3rd
    19 Files
  • 4
    Jun 4th
    21 Files
  • 5
    Jun 5th
    15 Files
  • 6
    Jun 6th
    12 Files
  • 7
    Jun 7th
    11 Files
  • 8
    Jun 8th
    1 Files
  • 9
    Jun 9th
    1 Files
  • 10
    Jun 10th
    15 Files
  • 11
    Jun 11th
    15 Files
  • 12
    Jun 12th
    15 Files
  • 13
    Jun 13th
    8 Files
  • 14
    Jun 14th
    16 Files
  • 15
    Jun 15th
    2 Files
  • 16
    Jun 16th
    1 Files
  • 17
    Jun 17th
    18 Files
  • 18
    Jun 18th
    15 Files
  • 19
    Jun 19th
    22 Files
  • 20
    Jun 20th
    15 Files
  • 21
    Jun 21st
    15 Files
  • 22
    Jun 22nd
    2 Files
  • 23
    Jun 23rd
    1 Files
  • 24
    Jun 24th
    23 Files
  • 25
    Jun 25th
    0 Files
  • 26
    Jun 26th
    0 Files
  • 27
    Jun 27th
    0 Files
  • 28
    Jun 28th
    0 Files
  • 29
    Jun 29th
    0 Files
  • 30
    Jun 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2019 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close