Re: [PATCH] Vtable pointer verification (corruption/attach detection -- new feature

[Florian Weimer <fweimer at redhat dot com>]

On 11/01/2012 09:07 PM, Caroline Tice wrote:
> We have been developing a new security hardening feature for GCC that
> is designed to detect and handle (during program execution) when a
> vtable pointer that is about to be used for a virtual function call is
> not a valid vtable pointer for that call (i.e. it has become
> corrupted, possibly due to a  hacker attack).  We gave a presentation
> on this work at the Gnu Tools Cauldron in Prague last July.  We now
> have the implementation fully working and are submitting this patch
> for review.  We would like to get this into the next release of GCC if
> possible.

Thanks for posting this collection of interesting patches.

As far as I understand it, this changes ABI in the sense that every 
object file needs to contain the constructors that register the vtables, 
otherwise verification will later fail.  If this data could be emitted 
in a declarative fashion, it might be possible to emit it by default, in 
a separate ELF section.  This way, it is always there when needed, and 
it wouldn't have any performance impact if not used.

I didn't look at the actual permitted-vtable set lookup in detail.  How 
expensive is it?  C++ virtual method calls are efficient, but they have 
their problems.  The vtable needs relocation (contributing to startup 
cost), and we have the fragile base class problem (which severely 
constrains the evolution of separately-compiled base classes).  Assuming 
that we need the vtable check and it has non-trivial cost, it might make 
sense to revamp C++ virtual method dispatch altogether, addressing both 
security and modularity issues.

(Yes, I understand these two paragraphs go off in entirely different 
directions. 8-)

--
Florian Weimer / Red Hat Product Security Team