Use After Free (UAF)
vulnerabilities occur when the application frees an object on the heap, and
then tries to erroneously use it again (usually due to a stale pointer
reference to the freed object). A common exploitation technique to target a UAF
vulnerability is to try to reallocate heap memory between the time when the application
frees the memory and when it erroneously dereferences the stale pointer to the freed
memory. This reallocation would fill the “hole” left by the application when it initially
freed the object. The typical timeline of this type of attack is as follows:
The JavaScript “pattern” string above was carefully crafted to meet the following criteria:
For more information about the Low Fragmentation Heap, see:
1) Application
frees object on the heap
2) Attacker
reallocates objects on the heap
3) Application
erroneously dereferences freed pointer
Note that in normal
circumstances, A UAF would crash the program due to an Access Violation. However,
when the application is being exploited, the attacker’s reallocation serves 2
main purposes: 1) Make sure that there is data at the location pointed to by
the stale pointer so the application doesn’t crash on erroneous dereference and
2) Craft the data in the reallocation in such a way that the dereference would
help the attacker gain control over the Instruction Pointer (EIP on x86).
In Internet Explorer, exploits
often use JavaScript to reallocate freed objects on a heap with the Windows Low
Fragmentation Heap (LFH) policy activated and groom the backend heap in order
to eventually gain control over the Instruction Pointer. The connection between
JavaScript and freed objects is as follows:
"When string attributes of HTML objects are assigned in JavaScript, the strings are often stored in the same Front End LFH that the freed objects were stored in."
The significance of this statement is that attackers can craft maliciously formatted strings in JavaScript and have the strings fill holes left by the freed objects. In order to reallocate the holes left by the freed objects, the attacker must make sure the strings are of the same size as the freed objects, so that the stings will get allocated in the same LFH bucket as the freed object. Once the object of interest has been freed, and the attacker can assign those strings as attributes to an array of HTML nodes, and those strings are likely to be allocated on the same LFH as the freed object. Eventually, if this process is repeated enough, a reallocation of the “hole” left by the freed object would occur. This means that the next time the application dereferences the stale pointer (ie for a virtual function call), it would get the attacker’s string rather than the object it expects to be there. This would be how the attacker initially takes control of the Instruction Pointer. Below is an example of what this process may look like in JavaScript:
//create an array of HTML elements
whose string attributes we will assign later
for (var i = 0 ; i <
numObjects; i++)
objectArray[i]
= document.createElement('div');
/*
"prime" LFH by allocating
a few strings of the same size as the object of interest to enable the LFH
bucket for this allocation size
*/
for (var x = 0; x < primeAmount;
x++)
objectArray[x].title
= pattern;
//application allocates object here
//application frees object here
//fill the hole left by the freed
object assuming primeAmount < numObjects
for (var z = primeAmount; z
< numObjects; z++)
objectArray[z].title
= pattern; //attributes should be allocated on
LFH
//application erroneously uses object
here
1) It must be the same size as the erroneously freed object, so that it will be reallocated in the same LFH Bucket.
2) Its value must be specifically crafted to help gain code execution. For example, if the freed object was a C++ object with a V-Table pointer, one of the first few DWORDs must point to a location in memory which the attacker controls (usually via a Heap Spray of the backend heap) that contains a malicious V-Table. For more information, see prior article about V-Tables.
2) Its value must be specifically crafted to help gain code execution. For example, if the freed object was a C++ object with a V-Table pointer, one of the first few DWORDs must point to a location in memory which the attacker controls (usually via a Heap Spray of the backend heap) that contains a malicious V-Table. For more information, see prior article about V-Tables.
For more information about the Low Fragmentation Heap, see:
Great. Thanks !
ReplyDelete