Where are virtual tables really stored, and why can't we modify them?

Question

I know the vtables are stored as read-only in memory to prevent modifications. Which section is exactly storing vtables?

Another question, according to read-only privileges that vtables have, how they got modified in exploit writing process?

Highly compiler and platform dependent. – Nikolai Fetissov Aug 23 '12 at 17:24 — Nikolai Fetissov, Aug 23 '12 at 17:24
And what about modifications? – n1kita Aug 23 '12 at 17:29 — n1kita, Aug 23 '12 at 17:29

score 7 · Answer 1 · answered Aug 23 '12 at 17:25

7

Where do you get the idea that vtables are stored in readonly memory? A vtable implementation is completely compiler defined and there is no guarantee they're read-only at all. I would imagine in many implementations they may be stored in writable memory, for example if write protection isn't available.

Even if the vtable itself is write-protected there's no reason you can't change the vtable pointer within an object instance to point to memory of your choosing that looks like a real vtable, exploiting that to jump to a different function.

answered Aug 23 '12 at 17:25

Mark B

95,107
10
109
188

2

FWIW: vtables are indeed in writable memory everywhere I know. The reason is that in general the functions they contain are dynamically bound. It's legal to derive from a class defined in a separate shared library, thus the pointers in the vtbl are going to be runtime-dependent. I'm sure it's possible to make a purely static vtbl for static binaries, but I'm not aware of anyone who does. – Andy Ross Aug 23 '12 at 17:51

score 3 · Answer 2 · answered Aug 23 '12 at 17:25

First of all, the virtual method tables is an implementation detail of the majority of C++ compilers. Furthermore, the compiler is not obliged by the standard to store the virtual table in read-only memory (this is clear, taking into account that C++ doesn't require the target hardware architecture to have read-only memory at all). So not all the compilers do that; some of them may do, some may not -- even if the read-only memory is available.

Next, provided that on some system some C++ complier uses vtables and declares them for executable loader to be loaded into read-only memory: if the loader is able to change the memory status to read-only, on some architectures a program with enough rights may be able to change it back. If however the memory is physically read-only, there is no way to modify it even by the executable loader, so the program must live in some variant of ROM. This is definitely possible, and in this case (hardware-protected read-only memory) there is no way to overwrite it maliciously.

Where are virtual tables really stored, and why can't we modify them?

2 Answers2