This is the mail archive of the
mailing list for the glibc project.
Re: Alternative libio vtable hardening approach
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Kees Cook <keescook at chromium dot org>, Yunlian Jiang <yunlian at google dot com>
- Date: Tue, 31 May 2016 11:09:58 -0400
- Subject: Re: Alternative libio vtable hardening approach
- Authentication-results: sourceware.org; auth=none
- References: <b34105f2-adcb-9347-73c0-43079729c418 at redhat dot com>
Overall the patch looks great. I like the idea, it's fast, and simple
to review and implement.
We need to store some state regarding the vtable checking and there is
no way to avoid that, either TP+offset or global are some of our cheapest
The question I'm asking myself is: Should we be pointer mangling any of
these pointers to make it harder to scan for the table?
> The attached patch is not completely finished. We need to disable
> vtable validation on both sides of a static dlopen boundary because
> the vtables are not shared across the boundary. This is what causes
> dlfcn/tststatic2 to fail.
How do you plan to disable the hardening at the static dlopen boundary?
I can see it being simple to disable the checks entirely for static
binaries, but the dlopen'd runtime won't know that and it will continue
to want to check the vtable values for any FILE objects passed to functions
of the loaded dynamic runtime? It seems to me that we're up against the
same problem of shared state across static/dynamic that we have discussed
What we really want is a set of internal initializers that are run during
static dlopen / dlmopen that allow the library to copy key state into the
I don't suggest that this block your forward progress on this issue
thought, I'm just raising the fact that I don't know how to solve this
> A future optimization would change the virtual function calls to
> compare the function pointer in the vtable against an expected
> function pointer. Only if that comparison fails, the vtable pointer
> is validated. This will allow us to inline parts of xsputn into
> vfprintf, especially if we change the various implementations to
> share more code.
You suggest this because a pointer comparison is cheaper than an
address range comparison? Could we make the tables read-only and use
another flag to elide all checking?
> At this point, I'm mainly interested in comments whether the use of
> the flag is acceptable from a security perspective. I expect that if
> you can set the flag and overwrite vtable pointers, you already have
> substantial control over what the process does. It is also likely
> that you would able to reset the pointer guard variable, disabling
> the hardening in Kees' patch.
Agreed. My only worry is static dlopen.