CVE-2015-2900

With one useful exploit primitive acquired, I moved on to the partially controlled arbitrary memory write vulnerability. This particular bug was discovered from a crash while running my dumb fuzzer. It appeared to be from a user controlled index (signed integer) added to a heap pointer address that resides in the data section. The containing function failed to validate whether the passed integer was greater than zero. The reason I refer to this vulnerability as partially controlled is because the heap address the index is being added to, is dynamic. Here’s some pseudo-code showing the bug.

After some investigation, I discovered that the heap address that is added to our controlled index is located below our string concatenate buffer from CVE-2015-2901. This means that we can leak this address and fully control where this write is happening. As you can see from the code snippet, the value being written is a heap pointer that was allocated just prior to the arbitrary write. We now have the beginnings of an exploit chain!!

So now that we know we can write a pointer almost anywhere in memory, the next step is to determine if we control the data being pointed to and locate a useful destination address to overwrite with our pointer. In a perfect scenario, we would overwrite a function pointer and then trigger a call to gain code execution. This assumes however, that the data being pointed to is controlled and executable. Searching through the binary, I was able to locate only a handful of function pointers that were located at static locations. Lucky for us, one of these function pointers is directly accessible from one of the message parsing functions. At this point I decided to cobble together everything I had so far and throw it at the application. To my amazement, it appears that we have achieved code execution on the heap.