Zbr's days.

About :: TODO :: Blog :: RSS :: Old blog :: Projects :: GIT :: Gallery :: Notes

Thu, 08 Feb 2007

Glibc function pointer encryption.

It was actually committed years ago - at the end of 2005, but Ulrich Drepper only announced it quite recently. Here is bits of presentation:

One of the remaining attack vectors in the runtime are function pointers in writable memory. Overwrite the value and you can redirect execution. Of course the pointer must actually be used and randomization must be overcome, but it's theoretically possible.

The remedy I've implemented in libc internally is to encrypt function pointers. I.e., they are not stored as-is but instead in a mangled form. This mangling consists in my code of XOR-ing the pointer value with a random 32/64-bit value. Each process has its own random value. The code was publicly committed back in December 2005 and is in FC6.

What is protected? I hope meanwhile most function pointers in libc. Some are probably still missing and others cannot be handled this way since they are visible to the outside. For some broken programs (including UML) the setjmp change was the biggest. These programs tried to access the stored code address which now is not really useful anymore (program don't know how to decrypt the value). Other pointers which are encrypted are the iconv and atexit structures as well as some function pointer tables people don't really know about, they are completely internal.
But let's see, what exactly is implemented? Searching for PTR_MANGLE/PTR_DEMANGLE macros shows, that only some registers in setjmp() code and atexit() and iconv related pointers, all of them are stored in private areas already, and hacker will crack his head just to find, for example, list of exit functions to change. It is much easier to overwrite GOT for example or implement other 'return-to-glibc' technique, instead of searching for private function pointers in the glibc...
And even that encryption is not that complex - pointer is XORed with value stored in TCB at fixed location from the start, so if attacked can access %gs register, he knows that secret value.

It is of course a good step, but it does not provide any real security, which is advertised by RedHat.

Likely it was the only reason I started to upgrade FC5 to FC6 - I wanted to check how pointers are encrypted and tried to determine if it is possible to hack that.

/devel/other :: Link / Comments ()