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

[Adhemerval Zanella Netto]

On 23/06/26 04: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.

The index would a better refactor indeed; although I think the wide vtable
would be slight simpler to implement.

But there is another question to how long should we keep this libstdc++
compat support, since it is hindering the stdio support with an overcomplicated
implementation.

My guess is without the need to keep supporting the vtable we will close
most if not all the current security issues.  On last Cauldron I asked if
we could start by making the _IO_file compat symbols, and eventually remove
them altogether. It would be an ABI break, but I think it is time to serious
evaluate this option.

> 
>> 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
>