In this post, i will be talking about a heap overflow vulnerability that i found in Resource Tuner v1.99 R6. This heap overflow can be exploited to execute code arbitrarily. The vulnerability occurs despite checks implemented by Resource Tuner.
As you see in the image below, the string (RT_STRING) resource has the RVA (relative virtual address) and size of the strings set to 0x3060 and 0x36.
If we change the "size" field to something like 0x7FFFFFFD, we can corrupt the heap.
Now let's have a quick look at this in OllyDbg.
I will dissect the vulnerability into 5 parts for sake of clarification.
Step (1)
The value of the "size" field is fetched and stored locally at dword ptr[ebp-60] .
Step (2)
The value of the "size" field is then passed to the function at 0x5330F0 (in disassembly in the image below, i named it as "AdjustInteger"). Upon return of the "AdjustInteger" function, we have 0x80000000 as the new size.
Step (3)
The new size value (0x80000000 from step 2) is then incremented and passed to the function at 0x4026A8 (let me name it as "allocateHeapCached"). The "allocateHeapCached" 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.
Step (4)
The function at 0x00402B14 ("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. Cool!!!.
Step (5)
The function at 0x004027E0 ("memcpy" equivalent) is called with the "num" parameter set to the huge integer stored at dword ptr[ebp-60] (from step 1) causing heap corruption.
A Proof Of Concept can be found here. Tested on XP SP3.
You can follow me on Twitter @waleedassar
As you see in the image below, the string (RT_STRING) resource has the RVA (relative virtual address) and size of the strings set to 0x3060 and 0x36.
If we change the "size" field to something like 0x7FFFFFFD, we can corrupt the heap.
Now let's have a quick look at this in OllyDbg.
I will dissect the vulnerability into 5 parts for sake of clarification.
Step (1)
The value of the "size" field is fetched and stored locally at dword ptr[ebp-60] .
Step (2)
The value of the "size" field is then passed to the function at 0x5330F0 (in disassembly in the image below, i named it as "AdjustInteger"). Upon return of the "AdjustInteger" function, we have 0x80000000 as the new size.
Step (3)
The new size value (0x80000000 from step 2) is then incremented and passed to the function at 0x4026A8 (let me name it as "allocateHeapCached"). The "allocateHeapCached" 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.
Step (4)
The function at 0x00402B14 ("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. Cool!!!.
Step (5)
The function at 0x004027E0 ("memcpy" equivalent) is called with the "num" parameter set to the huge integer stored at dword ptr[ebp-60] (from step 1) causing heap corruption.
A Proof Of Concept can be found here. Tested on XP SP3.
You can follow me on Twitter @waleedassar
No comments:
Post a Comment