Some versions of GLIBC bundled with popular distros still place their libio vtables in a writable segment. E.g. Ubuntu 1904 (which uses GLIBC 2.29) exhibits this behaviour, whilst the earlier Ubuntu 1804 (which uses GLIBC 2.27) does not. This could be a choice on behalf of the distro maintainers but it seems unlikely. Vtable pointers are still checked before dereferencing but I feel this is undermined somewhat by the fact that the vtables themselves are mapped writable. Perhaps the issue is in the Makerules file, around line 549, which is commented "If the linker is good enough, we can let it use its default linker script." The issue seems to manifest depending on the preceding ifeq statement's result. I'm not well versed enough in the workings of linkers to comment as to why this might be, but I've experienced the same writable vtable issue whilst building GLIBC using more recent versions of GCC.
This is a really interesting and informative post. Good job ! keep it up, hope to read your other updates. https://www.reddit.com/r/AndroidtoPCandMac/comments/f79k3w/how_to_easily_play_subway_surfers_in_pc/
I'm actively working on this.
Patch with test case posted: https://sourceware.org/pipermail/libc-alpha/2022-April/137700.html
Fixed for glibc 2.36 via: commit 198abcbb94618730dae1b3f4393efaa49e0ec8c7 Author: Florian Weimer <fweimer@redhat.com> Date: Mon Apr 11 11:30:31 2022 +0200 Default to --with-default-link=no (bug 25812) This is necessary to place the libio vtables into the RELRO segment. New tests elf/tst-relro-ldso and elf/tst-relro-libc are added to verify that this is what actually happens. The new tests fail on ia64 due to lack of (default) RELRO support inbutils, so they are XFAILed there. I'm flagging this as security- because it is just a lack of intended hardening, but not a vulnerability as such.