One of the most obvious attacks is if two different typed objects have similar memory layouts you can use it to read/write fields.
Say you had class A and class B and they are confused with each other.
Suppose they have the following layout:
struct A {
int x
void *f()
}
struct B {
int x
int y
int z
}
Then if you have a class A and you make the program think it's actually class B. You can imagine that if you control an object B you can update the fields x, y of a object B. Once this is prepared you can then use the object as type A and then run some code to trigger the call to A.f()
Obviously this is a trivial example but with depending on the vulnerability you can perhaps use it call protected functions and all kinds of memory corruption.
Attacks on JavaScript arrays tend to edit the 'size' field and change it to a really really large number, thus by simply indexing the array you can have unrestricted read/write access to a large section of memory.
> indexing the array you can have unrestricted read/write access to a large section of memory.
but won't the memory protection (write xor execute) stop the function pointer from jumping to the array body (since that's write memory)? Meh, i guess in actual practise, it's much more complicated than that...
Say you had class A and class B and they are confused with each other.
Suppose they have the following layout:
Then if you have a class A and you make the program think it's actually class B. You can imagine that if you control an object B you can update the fields x, y of a object B. Once this is prepared you can then use the object as type A and then run some code to trigger the call to A.f()Obviously this is a trivial example but with depending on the vulnerability you can perhaps use it call protected functions and all kinds of memory corruption.
Attacks on JavaScript arrays tend to edit the 'size' field and change it to a really really large number, thus by simply indexing the array you can have unrestricted read/write access to a large section of memory.