This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Alternative libio vtable hardening approach
- From: Florian Weimer <fweimer at redhat dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>, Kees Cook <keescook at chromium dot org>, Yunlian Jiang <yunlian at google dot com>
- Date: Wed, 1 Jun 2016 10:34:56 +0200
- Subject: Re: Alternative libio vtable hardening approach
- Authentication-results: sourceware.org; auth=none
- References: <b34105f2-adcb-9347-73c0-43079729c418 at redhat dot com> <20160531221137 dot GD7717 at vapier dot lan>
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