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
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
- 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.