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
