A specially crafted web-page can cause an integer underflow in Microsoft Edge.
This causes CTextExtractor::
to read data outside of the bounds
of a memory block.
Microsoft Edge 11.
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.
Though I did not investigate thoroughly, I did find out the following:
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.WCHAR
before the start of the buffer, which is
normally also in allocated memory.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.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.
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.
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.
Exploit.Id: | AVR:Arbitrary 553. |
Description: | Access violation while reading memory at 0x5BDF4F139E |
Location: | microsoftedgecp. |
Security impact: | Potentially exploitable security issue |
Id: | AVR:Arbitrary 553. |
Description: | Access violation while reading memory at 0x3D945C439E |
Location: | microsoftedgecp. |
Security impact: | Potentially exploitable security issue |