Bugtraq: Google Chrome Accessibility blink::Node corruption details

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

http://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 http://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

—–BEGIN PGP PUBLIC KEY BLOCK—–

Version: GnuPG v2

mQINBFeg3+kBEACfJ83XEx+3CXfc2pyDlZ5+DFSvhdvbSvemqEckOtrQxTYOmH/8

6WrX2B7K6eyolLCIQMi0FjXK5hjJJFYTMrhoa7pP9V9PD2f4TI+tZv+g0D8wDVam

wYsZrFB6NwzyUaBykjj4chYxxzUxTwagwCxvrGNY871tiVWV5eR3TrKRcsFwzN53

G3lhAT974YRCIBMuA6y+3Jrd8hgfODWUtYsH4WPhaLJRr9qaatN+Fnpk+rb9X62C

EqcVXhgNeIz1j/K3I3XoHqMThNu5zbv7uQrp2j+/0fZjKXxZ7HZhTKzIFTrJkrTA

jQ34iq0qgXmLltpKtOLJKhPQPb8J/N0MxOOTa34BDeSiqwlcRzkl7lYTIl7hvvCn

lSRbu+PoAW0GrD17RAA9FQoqdDDiNLHlXnjx7Jg/Tchq1EF70hKzMojcwyjPilty

HJRtPq/sZEdjwEuA5fM+3cmkmRWZYXmn93rB2KTNlGXo+7II6eXx1E6iw7MBzhV5

+mB9A/6FLPhb6TY7TrWOKC65uEtYjHArcb2WeB7/6g9r0nPcBzFiXt35U+YdbmiH

Qt4L5aivYI3WNwQh391Q8QH8i1C0DTI0TCoinzBHzySJfiQ5IP8BUmPIKJWxSeiF

Od5Fv3bz7S7DihtP+i7XyChoHVAleu9tk4/kIQlJ/PPbBpRAYFhQKwSX3QARAQAB

tCRCZXJlbmQtSmFuIFdldmVyIDxiZXJlbmRqQG53ZXZlci5ubD6JAj8EEwEIACkF

Aleg3+kCGw8FCQIDCbcHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCdHa2I

JVfFqn6TD/0aQmgvFcwoAOn52NujoEgl5LxdvcrPgDaZK10kuolsA2u/IaB4J3yY

c2Z8kTfGOg5ObCBHlq6B9qYn3ptr+C0ICuYENIVoHdcBgdK9JXscRWrOU8JI69mj

gmsKNLei+AuBGGC7LJOV6JNqYkVieukkFQkv17pvFl63GqNcVkwEXIzzeGOHYHqA

dvPR7xTZu+dA2olB2BVC9XsWJpsxJqzuX8L3wOEn1EFAhlbeSlBo2kXB04DnjUXU

qHa9M2PZ4q0xWmD+iAThTdyoB+FvSvn6+ThFhig99dOsx8ZLS/QRwMoq1qgN1Nst

YFZgCUuGqwR7d0Dr8/Vb1qzQmIPtn/JCjbFNuIssGRA3tDVwTvEmgfAhpVApuS8f

bNWGV2fQmEfLShqXOI/GfEYt8ltoozKKTYRiXt7oqsrLGWjXJ6SZAYcFHOCc9CbC

TukyDyndVIWAwJRSr9SHKyokElnJBeiGW9rMwITW4BRf7YfXNwHHOFW95esbNIEF

sL37BfzBoTNDUShajB8kVKJv0LE5OZArsQfz2yBXoU2AyvGEvbYdt0q53+FwGzX/

EtqkcFYqwKkxurjn8Nkk4x4hjoiUmXHj45G/MgwLxY8Skf6RvBr0eu4Mh7FxoTRP

LX5hIpGbCO3umoGbHNGkJcEw5S9oIQdb3ysf5HVLi7Pw6AIfJZWSfIkBHAQQAQgA

BgUCV6S2FwAKCRBf2KWWmuk+Yng/B/0f/nSDAnmXAiZ2HPi/ujfAEzFPWmahZJVv

Ih9DjuRUV6vk1B9Sh+yiPPZ3FfqOzVE0n6Eh1Kggs6MwQCWv+NfC0KE6rQwxjMce

+eOAf9dbVQ8h6H4yGyIyb4f0tJFRyGpOK8zlKwjvPj2gvTZFjcc1PaZ7cIeuwheB

Ijtw9DQWIoQoFFHZkLHxmNo8IT+r7lB19rVWoh1pu/zfuC+xjQLCpzexafFGY3TT

Fz7YdO14F61sJjrf++9twRi7RoHWGnAcFCZynG6x4jyog1u9iKMK2T2nV5yyQg21

yhw4zEV1pKDwUdHK+TwmtyD5c6oL3IjNDWaHn0aejKgfEiiLUBLe

=anIL

—–END PGP PUBLIC KEY BLOCK—–

—–BEGIN PGP SIGNATURE—–

Version: GnuPG v2

iQIcBAEBCAAGBQJYPUVgAAoJEJ0drYglV8WqT1AP/1GpcI1/Nh7UKyFWkctbp42G

0nfUBzGgNBf6/1QdVKU35ScJoAuuaiYNvFduAiPhyV+9V38PIFOCv4pH1oz1A69b

ZbiKCmDp/57gRgtF7EDbPR2lkgHxIzxpb6YLb+1jfC63uulwV5Tan5ZNE1cktd44

d4lOEOji4LFwzCsrXRiIxDQSpnFe63aNR1AxA/ow7aEfQ8wdLdcPkgFYAZ1hIZiM

wAeXAMRMOOVr4IOVWAdpMZPnCk3dGpALc9K3HTg3ywV+nbBlo4bcJbqtQYcqFjV1

jhDhtg+Qiyz5W6FUxwTGIokGNC4YbH9UeHKuEBGHw2uFEiKeSv+WDNko8DXgpzca

kYj3h9zGdoHeSI6/udxBkj4CIdLh457JT6narl6PATRED+6Z1Nlmf8G8VR6NPdzK

k9z0r+qdL4GCh64JOqvdg+WhrXsBy+1J38s8/WuhPjY7HLgpK7fdX6OTifcW5GYX

uxoGHSZVOvyGBFxITtL6VmA7gcPyKQpUsSrkHxNOMmW/pbzMhzs/nP+oA6XKn6t7

XeKm9/3i8QCsWHXz3FNNxKK2YFvVt5a8rrJI1G8+TxiuyhhyAo84HBreEkkmhuxO

lGpfc6/Tn5zqmt732u5CdfDJ1+aVg5aHAvYdperRHEp8YIc0pyx0YAZ4BgCmWXdz

xdslbbJuzddYGlM6NMjK

=umAR

—–END PGP SIGNATURE—–

[ reply ]

Source: SecurityFocus Vulnerabilities @ November 29, 2016 at 05:05AM

0
Share