Re: [PATCH v2] libio: use PTR_MANGLE/PTR_DEMANGLE for FILE vtables

[Kees Cook <keescook at chromium dot org>]

On Thu, Oct 1, 2015 at 1:14 PM, Florian Weimer <fweimer@redhat.com> wrote:
> On 10/01/2015 09:40 PM, Kees Cook wrote:
>
>>>> How do you think this should best be handled? (Are there examples of
>>>> similar configure flags?)
>>>
>>> Probably something like this in configure.ac:
>
>>> And you need to update config.h.in.
>>
>> Thanks! I'll poke around...
>
> It's probably not needed if we come up with a completely
> backwards-compatible approach.
>
>>> libio.h is apparently an installed header, so it is still part of the
>>> public API.  This means that this API is technically supported on all
>>> current architectures, even those which never saw the old libstdc++
>>> version.  (libstdc++ switched in 2003â)
>>>
>>> This means that vtable mangling is very much a backwards-incompatible
>>> change.  We can still salvage this in some way.
>>
>> Well, no, I don't think that itself makes it backward-incompatible:
>> _IO_jump_t and _IO_FILE are opaque structures in libio.h. Am I missing
>> something?
>
> There is a full definition, and there is a widely-used getopt.c file
> which references it (although not the vtable bits).  Let's hope it's not
> actually unused. :-(

I can't find reference to the vtable portion of the structure outside
of the glibc sources.

> Functions like putc also use it.  Removing libio.h from the API likely
> breaks the papi package.
>
>>> Do you care mainly about statically linked libc, dynamically linked
>>> libc, or both?
>>
>> I care about both, but I tend to only use dynamic.
>
> In the dynamic case, we compile in all the vtables we need.  We should
> put them into an array, so that we can check easily if we have a
> known-good vtable.  If we deprecate libio API (remove the installed
> header and the default symbol version), we could set flag once we
> encounter a reference to a libio symbol, and when that happens, we set a
> flag that disables the vtable check.
>
> The difficult question is how many symbol version bumps we need for this
> to work.  Do we have to bump all stdio symbols, too, because someone
> could write their own _IO_FILE class and pass it to fread?

I can't find where it's possible to write one's own _IO_FILE class.

-Kees

-- 
Kees Cook
Chrome OS Security