heap commands do not currently work for stripped glibc versions >= 2.34

[theguy147]

The issue is that __malloc_hook was removed from the API in glibc version 2.34, which is the symbol which GEF uses as a hack to find the main_arena when the libc is stripped.
While a __malloc_hook symbol is still included in the glibc versions in question, it is just for compatibility reasons and it is not close to the main_arena anymore.

(source: https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html)

Executing any heap command does not currently work for the specified glibc versions as they all rely on the correct identification of the main_arena

[caprinux]

I have managed to make something work for some of the specified glibc versions a few months ago when I encountered this issue, but have yet to extensively test it. Anyone looking into this might wanna check it out

ecfd900

It takes a relative offset from the stdin file structure from within glibc --- _IO_2_1_stdin.

I feel like this commit may work from versions 2.34 onwards, and possibly even before 2.34 (untested). Would be great if someone with more time can look into this.

[theguy147]

Thanks for your input.

Even though we had this version of calculating the address of the main_arena through the __malloc_hook symbol, we are trying to reduce the "hackyness" of such calculations as they are highly version dependent and will eventually fail again (on a different glibc version or distribution or just a different architecture) and it is not easy maintaining them in the long run.

I am looking into an option to bruteforce the address of the main_arena on user request, but I haven't been able to get it to work on different architectures yet.

Bruteforcing seems feasible in this case as the search space is quite constrained (at least for dynamically linked executables):

• main_arena should be in .data of the linked glibc
• the start address of main_arena should be aligned to 0x20
• The next pointer of the arena should point to valid memory and form a cycle with the other arenas (so the last next pointer in the cycle should point back to main_arena).

These facts could be used to quickly retrieve a list of valid candidates, and if the length of this list is exactly one, then with a high probability the main_arena has been found.

I still need to check how to make this work on all architectures supported by GEF, and moreover if and how this could work in statically linked executables.

Unfortunately, it may take me some time to verify all this as I'm very busy at work with some big deadlines coming up.