Bug 25812

Summary: Libio vtable protection is sometimes only partially enforced
Product: glibc Reporter: Max <maxkamper>
Component: stdioAssignee: Florian Weimer <fweimer>
Status: RESOLVED FIXED    
Severity: normal CC: fweimer, luciham20
Priority: P2 Flags: fweimer: security-
Version: 2.31   
Target Milestone: 2.36   
Host: Target:
Build: Last reconfirmed: 2022-04-11 00:00:00

Description Max 2020-04-10 17:22:27 UTC
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.
Comment 1 Lucille F. Parham 2020-04-15 07:09:58 UTC Comment hidden (spam)
Comment 2 Lucille F. Parham 2020-04-15 07:11:23 UTC Comment hidden (spam)
Comment 3 Florian Weimer 2022-04-11 09:17:12 UTC
I'm actively working on this.
Comment 4 Florian Weimer 2022-04-12 11:27:54 UTC
Patch with test case posted: https://sourceware.org/pipermail/libc-alpha/2022-April/137700.html
Comment 5 Florian Weimer 2022-04-22 10:31:22 UTC
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.