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

[Caroline Tice <cmtice at google dot com>]

cmtice@google.com


On Wed, Jan 30, 2013 at 2:09 AM, Florian Weimer <fweimer@redhat.com> wrote:
> 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.

Yes.

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

That might be possible; it would need to be carefully organized
though.  If is not enough to have a list of all vtable addresses; we
need to know, for each virtual class (where by virtual class I mean a
class for which a vtable might be generated) the set of vtables that
is is legal for an object of that class to point to (i.e. for a base
class, it can point to its own vtable or to the vtable of any of its
descendants in the inheritance hierarchy).

>
> I didn't look at the actual permitted-vtable set lookup in detail.  How
> expensive is it?

The set up is expected to be somewhat expensive, although we are
trying to make it as efficient as possible.  We are in the process of
gathering performance data.

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

That might be best, but we don't have the authority to unilaterally
make a change of this magnitude to the standard. ;-)

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

Let me know if you have any more questions, or if you would like any
further clarifications.

-- Caroline Tice
cmtice@google.com

> --
> Florian Weimer / Red Hat Product Security Team