[RFC] libio FILE/vtable hardening ideas against FSOP-style attacks
Florian Weimer
fweimer@redhat.com
Tue Jun 23 07:57:33 GMT 2026
* 류대호:
> 1 Does validating the wide vtable path with IO_validate_vtable seem
> like a reasonable hardening direction?
GCC 2.95 did not have wide vtable support in libstdc++, so it's unlikely
there is ABI impact. This means we can replace the vtable pointer with
just an index into a vtable array. Validation would be a simple bounds
check. No fallback for old binaries is needed.
> 2 Is exact vtable start-address checking too strict for glibc, or
> could it be useful in some limited paths?
I think we should try to refactor this eventually and use
switches/conditionals instead of indirect calls for glibc's
implementations. The only widely used ABI that needs vtables is i386.
A good first step would be to identify the vtables we have, the
functions in them, and how many different implementations those
functions have.
> 3 Is a FILE metadata registry fundamentally incompatible with libio,
> or is it worth exploring as an optional hardening idea?
Some of the struct members are public, the buffer pointers in
particular. See getc_unlocked and putc_unlocked.
Thanks,
Florian
More information about the Libc-alpha
mailing list