This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Alternative libio vtable hardening approach

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]