exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

Google Chrome Accessibility blink::Node Corruption

Google Chrome Accessibility blink::Node Corruption
Posted Nov 29, 2016
Authored by SkyLined

A specially crafted web-page can trigger an unknown memory corruption vulnerability in Google Chrome Accessibility code. An attacker can cause code to attempt to execute a method of an object using a vftable, when the pointer to that object is not valid, or the object is not of the expected type. Successful exploitation can lead to arbitrary code execution.

tags | exploit, web, arbitrary, code execution
SHA-256 | 2e778c3221fa3eaf8abf088d1e8b32a2d106db4dc5bdebdb26527e31a4f3f729

Google Chrome Accessibility blink::Node Corruption

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
twenty-first 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
https://blog.skylined.nl/20161129001.html. There you can find a repro
that triggered this issue and relevant code snippets in addition to the
information below.

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

Google Chrome Accessibility blink::Node corruption
==================================================
(The fix and CVE number for this issue are unknown)

Synopsis
--------
A specially crafted web-page can trigger an unknown memory corruption
vulnerability in Google Chrome Accessibility code. An attacker can
cause code to attempt to execute a method of an object using a vftable,
when the pointer to that object is not valid, or the object is not of
the expected type. Successful exploitation can lead to arbitrary code
execution.

Known affected software and attack vectors
------------------------------------------
* Chrome 48.0.2540.0 dev-m

An attacker would need to get a target user to open a specially
crafted webpage. Renderer accessibility must be enabled through the
"--force-renderer-accessibility" command-line option. Disabling
JavaScript will not prevent an attacker from triggering the
vulnerable code path.

Description
-----------
Repeatedly loading two different pages in an iframe can cause the
accessibility code to crash. This crash can happen in two different code
paths, which are similar and both end up crashing because of a corrupt
`blink::Node` instance. The first code path calls
`blink::isDisabledFormControl` with the corrupt `blink::Node` instance
as an argument from `AXNodeObject::canSetFocusAttribute`. This causes an
access violation when `blink::isDisabledFormControl` attempts to call
the `isDisabledFormControl` method on the corrupt `blink::Node` instance.

The second code path calls `blink::Element::fastGetAttribute` with the
corrupt `blink::Node` instance as an argument from
`blink::AXObject::getAttribute`.

This can cause an access violation at various locations along the code
path, but almost certainly does so if the code reaches the part where it
attempts to match the attribute name, as the
`blink::AttributeCollectionGeneric<...>` was taken from a corrupt
`blink::Node` instance and that data is therefore almost certainly
completely invalid.

Exploit
-------
Is is unclear to me why the `blink::Node` instance was corrupted. During
analysis, I was having trouble running Google Chrome with Page Heap
enabled, which severely limited my ability to reliably crash the
application and find out what information on the heap belongs to what
object. Then, before I could get my debugging environment fixed, the
issue appears to have been fixed, as I was no longer able to reproduce
it. Any information on exploitability is therefore based on speculation.

An attacker who is able to trigger the issue reliably, and has some
control over the corrupted `blink::Node` instance that is returned, or
heap memory in this area, may be able to control execution flow through
the `blink::isDisabledFormControl` call, as this uses information from
the corrupted `blink::Node` instance as a pointer to a vftable.

Time-line
---------
* October 2015: This vulnerability was found through fuzzing.
* November 2016: Details of this issue are released.

(This issue was never reported, as I was struggling with my debugging
environment, as described above. At some point after I discovered it,
this issue appears to have been fixed, as evidenced by the repro no
longer working. However, I have no exact date, nor a fix number to
provide here).

Cheers,

SkyLined


Repro.html

<iframe id=x></iframe>
<script>
var u = 0;
onload = x.onload = function () {
x.src = "Target" + (u++ % 2) + ".html"
}
</script>

Target0.html

<form>
Target1.html
<canvas><object id=a>x

Login or Register to add favorites

File Archive:

September 2024

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

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2024 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close