[RFC] libio FILE/vtable hardening ideas against FSOP-style attacks

[Daeho Ryu]

Thank you, Florian, for the explanation.

I had assumed that changing the vtable structure itself would be 
difficult because of ABI compatibility, so my initial thought was to 
look at a smaller validation step for the current wide vtable path.

Your comments make sense to me. If the wide vtable part does not have 
the same compatibility constraints, then replacing the pointer with an 
index, or eventually using switches or conditionals for glibc's internal 
implementations does seem like a cleaner direction.

For my own understanding, if there is any existing discussion, previous 
work, or ongoing work on this refactoring direction that I should read 
first, I would appreciate any pointers.

I will also start by looking into the existing libio vtables, their 
function slots, and how many different implementations each slot has, as 
you suggested.

Thanks,
Daeho


On 6/23/26 16:57, Florian Weimer wrote:
> * 류대호:
>
>> 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
>