Alternative libio vtable hardening approach

Florian Weimer fweimer@redhat.com
Tue May 31 13:21:00 GMT 2016


I have implemented a completely different approach to vtable hardening.

The basic idea is to put all libc vtables into a single array, and then 
check whether the vtable pointer is within that array.

There is a new flag, IO_accept_foreign_vtables, which is initially false 
and set to true to indicate that vtables may have been defined outside 
of libc.  This allows us to preserve full backwards compatibility.

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.  We also may have to set the 
IO_accept_foreign_vtables flag for additional constructor functions 
(although _IO_file_init may be sufficient, based on what I have seen in 
GCC).

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.

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.

Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libio-vtable.patch
Type: text/x-patch
Size: 84872 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20160531/5fbbfd09/attachment.bin>


More information about the Libc-alpha mailing list