BugTraq
CVE-2016-3247 Microsoft Edge CTextExtractor::GetBlockText OOB read details Nov 18 2016 10:32AM
Berend-Jan Wever (berendj nwever nl)
Throughout November, I plan to release details on vulnerabilities I
found in web-browsers which I've not released before. This is the
fourteenth 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/20161118002.html.

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

Microsoft Edge CTextExtractor::GetBlockText OOB read
=====================================
(MS16-104, CVE-2016-3247)

Synopsis
--------
A specially crafted web-page can cause an integer underflow in Microsoft
Edge. This causes `CTextExtractor::GetBlockText` to read data outside of
the bounds of a memory block.

Known affected software, attack vectors and mitigations
-------------------------------------------------------
* Microsoft Edge 11.0.10240.16384
An attacker would need to get a target user to open a specially
crafted web-page. JavaScript is not necessarily required to trigger
the issue.

Description
-----------
Though I did not investigate thoroughly, I did find out the following:
* The root cause appears to be an integer underflow in a 32-bit
variable used in `CTextExtractor..GetBlockText` as an index to read a
`WCHAR` in a string buffer. This index is decreased once too often
and becomes -1, or a very large positive number depending on how it
is used.
* This does not result in a crash on 32-bit systems, as an integer wrap
causes the code to read one `WCHAR` before the start of the buffer,
which is normally also in allocated memory.
* On 64-bit systems, the 32-bit -1 value is interpreted as 0xFFFFFFFF,
a very large positive value. As this is an index into a `WCHAR`
string, it gets multiplied by two and added to the start of the
buffer to find the location of a `WCHAR` to read. This causes the OOB
read to be around 8Gb (!!) beyond the address at which the buffer is
allocated.
* The crash happens in code that appears to be rendering the web-page,
which does not immediately offer an obvious way of extracting
information using this bug.

Exploit
-------
This is where it gets interesting, as the OOB read happens
approximately 0x2`00000000 bytes after the address at which the buffer
is allocated. This presents us with a problem: how to store some
information that we'd be interested in reading at such a large offset
from the original allocation?

As one might come to expect from me, I used a heap spray. But it needed
to be a special kind of heap spray as I did not want to actually have to
allocate 8Gb of RAM. However, about ten years ago (boy, time flies!) I
developed a heap spray that uses significantly less RAM than a
traditional heap spray does; in practice probably about 33% in most
cases, but theoretically much more in ideal situations. I've been
meaning to blog about it, but never found the time to do so until today:
you can read all about it here:

http://blog.skylined.nl/20161118001.html

That said, I have not actually looked at whether it is possible to
exfiltrate useful information using this bug. However, I did write a
Proof-of-Concept that attempts to make sure something is allocated in
the area where the OOB read happens. This PoC uses these heap spray
tricks to spray the heap while minimizing memory use. The
Proof-of-Concept uses about ~5.3Gb to allocate the memory at around 8Gb
distance from the buffer (up to ~10Gb to be sure). When you load the PoC
in a 64-bit version of Edge, you may notice that, unlike the original
repro, it will not crash Edge (even though it does trigger the
issues): the heap spray has allocated the memory that the out-of-bounds
read accesses, and this prevents an access violation exception.
Refreshing the page is likely to screw up the precise allocation process
needed and will probably cause a crash.

This proves that it is theoretically possible to allocate information at
the address used by the code. All that is left is prove that the
information read by the code can be exfiltrated somehow, and you have a
working exploit. This is left as an exercises to the reader.

Time-line
---------
* June 2016: This vulnerability was found through fuzzing.
* June 2016: This vulnerability was submitted to ZDI and iDefense.
* July 2016: This vulnerability was acquired by ZDI.
* September 2016: This vulnerability was addressed by Microsoft in
MS16-104.
* November 2016: Details of this issue are released.

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

iQIcBAEBCAAGBQJYLti4AAoJEJ0drYglV8WqyfwP/133y9ihxxKuDxsXiNQwgRmY
2c3We6HfTpU/2WzUnMjhcmgaVy98AB/wmbF5Uh+h4dRim+0EO0irycoMGP4qLXcN
HAzOJbhaZkB8+aqicNPhwa8BEnG8XkDN0KFlBMmGFIWu0HSpP0LOtSHBko//52XY
FHvDomJ6G6RoBFsb5OOyKIlUlegC32PzVxuTeCaqMOgIebr2ZL0ttxsl/Zp9wVsI
gKcnbMrq1OcjN51NA3q4+2UNV0PIu3USi9ojp8y2VdsiKkh0/wDGzxsmgkSgnRi8
/QtU7uJYK17iVLwN618M+6Kumst4MIEhfJOnT8ygx+YNongidqE4wBXxLmHc1Qx0
dXi7vK4pUYV93t8MDEtvtnCncTMlhqOoqOELDRbHa5Cd9V+FQbprR/iqkyi9q4yP
pq8TFgjcMKa/t6E4LM6o5iMWmktx56+7zNn0DYdg9OrWN4daI2hKoWbf/hgIuUuc
CB6Zw6BTf6XEWRcPaAIL1peDCVveFvR6LFUe6vA12cbeZyVyuSHWobUDwaLdkx1T
i4RkX0+uAOpy3PO1qYujwBTIKS0mHYdCqcuIWwghz7jsdUMWuewkulNsI4c/dcdb
CPe1FhPZYAPauvYqC4X/js+vE21Erx4mg4xLjmYhZnxMRBq8aFPNoUdzor+5SIuP
nlh5q4Oo7UeZMLFyatUa
=/1Vf
-----END PGP SIGNATURE-----

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus