Bug 25812 - Libio vtable protection is sometimes only partially enforced
Summary: Libio vtable protection is sometimes only partially enforced
Alias: None
Product: glibc
Classification: Unclassified
Component: stdio (show other bugs)
Version: 2.31
: P2 normal
Target Milestone: 2.36
Assignee: Florian Weimer
Depends on:
Reported: 2020-04-10 17:22 UTC by Max
Modified: 2022-04-22 10:31 UTC (History)
2 users (show)

See Also:
Last reconfirmed: 2022-04-11 00:00:00
fweimer: security-


Note You need to log in before you can comment on or make changes to this bug.
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.