I have found a vulnerability in PE Explorer v1.99 R6. This heap overflow can be exploited to execute code arbitrarily. It is similar to the one of Resource Tuner shown in a previous post.
The vulnerability occurs due to an insufficient check for the size of memory to be allocated. It can be triggered by manipulating the "Size" field of any RT_STRING resource. Other resource types may also be subject to the same vulnerability.
If we change the "Size" field to a value like 0x7FFFFFFF, we can easily corrupt the heap.
I will dissect this vulnerability into 5 parts for sake of clarification.
The value of the "size" field is fetched and stored locally at [ebp-48] . So, we now have 0x7FFFFFFF at [ebp-48].
The value of the "size" field is then passed to the function at 0x571CD4 (in disassembly in the image below, i named it as "AdjustInteger"). Upon return of the "AdjustInteger" function, we have 0x80000000 as the new size. The new size is stored locally at [ebp-44].
The new size value (0x80000000 from step 2) is then incremented and passed to the function at 0x4026A8 (the one responsible for heap allocation). This function converts its input value into an index. The index is then used to extract a memory block of corresponding size. At the point of converting the requested size into an index, the huge value is truncated into a smaller value and a much smaller memory block than requested is returned.
The function at 0x402B14 ("memset" equivalent) is then called with the huge value as its "num" parameter. Luckily, the function quickly returns if the "num" parameter is a signed value.
The function at 0x4027E0 ("memcpy" equivalent) is called with the "num" parameter set to the huge integer stored at [ebp-48] (from step 1) causing heap corruption.
A Proof Of Concept can be found here. Tested on XP SP3.
N.B. Increasing the size of the resource increases chances of corrupting the heap, something that can kill all functionalities of PE Explorer.