How can a modern Windows/Linux system be compromised by a heap overflow in Chrome?

Question

Wikipedia's article on Heap Overflow states:

there are primarily three ways to protect against heap overflows. Several modern operating systems such as Windows and Linux provide some implementation of all three.

• Prevent execution of the payload by separating the code and data, typically with hardware features such as NX-bit on modern systems.
• Introduce randomization such that the heap is not found at a fixed offset.
• Introduce sanity checks into the heap manager.

With these protections in place, how could a recently discovered exploit through heap overflow in Chrome's PDF reader occur?

By simply viewing a PDF document that includes an embedded jpeg2000 image, the attacker can achieve arbitrary code execution on the victim’s system

Source: PDFium Vulnerability in Google Chrome Web Browser

Answer 1

Here, the vulnerability does not talk about some program running on your machine. The problem is data being overwritten at the wrong place. You can find the details of the vulnerability here: http://blog.talosintel.com/2016/06/pdfium.html#more

As mentioned in the webpage:

If in the above call to opj_calloc, which is a calloc wrapper, numcomps value happens to be zero, calloc will return a unique pointer which can be later passed to free (this is implementation dependent, but is so on modern Linux OSes). The unique pointer returned by calloc will usually be a small allocation (0x20 bytes in case of x64 code). This can lead to a heap buffer overflow later in the code when this buffer is being used.

In the above code, l_tccp pointer will be pointing to the previously erroneously allocated area. The same structure is dereferenced during further out of bounds writes in the following code.

Since writing to memory owned by a program is a valid process, an operating system cannot block the above mentioned process.

• Prevent execution of the payload by separating the code and data, typically with hardware features such as NX-bit on modern systems.

This is not working because there is no execution of a payload here.

• Introduce randomization such that the heap is not found at a fixed offset.
• Introduce sanity checks into the heap manager.

We are explicitly fetching the location to be read from/written to and hence randomization will not work here. This is a simple case of a missed sanity check.

Also, as mentioned in the webpage the Chrome build system already had a fix for it in place, just not in the correct build. The bug has been fixed now.