Alternative libio vtable hardening approach

[Florian Weimer]

On 06/01/2016 12:11 AM, Mike Frysinger wrote:
> On 31 May 2016 15:07, Florian Weimer wrote:
>> 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.
>
> by that logic, why do we have PTR_MANGLE at all ?

I looked at this some more.

I guess it's somewhat difficult to overwrite the pointer_guard cookie in 
the TCB.  Main thread and additional thread initialization are both 
right in the middle of functions, so you need to know the TCB address. 
I assume this is what it makes effective (if it is, I don't know).

The downside is that once the guard value leaks, it loses its 
effectiveness.  The vtable validation approach is not based on a secret 
and thus doesn't have this property.

> seems like it'd be possible to use to arbitrary points to use as the
> false/true values if we really wanted.  i.e. turn the new bool into a
> pointer, then for "true", assign it a mangled value of the vtables
> array, and for "false", assign it a mangled value of some other sym.
> then even if someone could corrupt the variable, they wouldn't be
> able to just stamp in "0" or "1".  only one or two points would need
> to be updated, so the ugliness would be contained.

Good idea.  It's easy to implement, and only the compatibility paths are 
affected.

(There is another caveat, see Kees' about the process opting out.)

>> +      JUMP_INIT(finish, _IO_file_finish),
>
> i know the old code got the style wrong, but since you're writing a
> whole new file from scratch, might as well fix the style issues too.

I'm going to turn this into a designated initializer and remove the 
macro altogether.  Currently, the macro drops the first argument.

Florian