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: use-after-free / double-free exploit mitigation

On 09/09/2017 11:59 AM, Federico Manuel Bento wrote:
On 09/06/2017 02:46 PM, wrote:
What are your thoughts on adding a SAFE_FREE() macro to glibc:

#define SAFE_FREE(x) do { if((x) != 0x0) { free(x); (x) = (void
*)0x1; }
} while(0)

After free(x), we set x to an address that will crash when dereferenced
(use-after-free), and will also crash when it's an argument to free().
Note that NULL isn't used, because free(NULL) does nothing, which might
hide potential double-free bugs.

Maybe GCC should optionally do this for the actual call to free. There
is some debate to what extend pointer *values* remain valid after free.
Martin Sebor may have some thought on that.

In any case, some GCC assistance is needed so that

free (some_struct->ptr);
free (some_struct);

actually clobbers some_struct->ptr. I don't think we want to call out
to explicit_bzero here.

One of the advantages of doing this in the compiler (besides not
having to change source code) is distinguishing rvalues from lvalues.


Perhaps this sould be used when making use of FORTIFY_SOURCE?

That seems reasonable.  David Malcolm has done some preliminary work
on a GCC maaloc/free optimization and diagnostic pass that might be
well suited to this sort of instrumentation.  Opening an enhancement
request in GCC Bugzilla for this would help track interest in
the feature.


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