This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Alternative libio vtable hardening approach


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
other namespace.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]