use-after-free / double-free exploit mitigation

use-after-free / double-free exploit mitigation

[up201407890]

Hello list,

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.

The pointer passed to free() isn't always an lvalue we can assign to,  
e.g free(func()), but when a var is used it will detect use-after-free  
and double-free bugs by having the program crash instead of allowing  
various heap grooms and further exploitation.


Here's a trivial example,

Crashes when use-after-free:

$ cat test.c
#include <unistd.h>
#include <stdlib.h>

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

struct unicorn_counter { int num; };

int main() {
     struct unicorn_counter* p_unicorn_counter;
     int* run_calc = malloc(sizeof(int));
     *run_calc = 0;
     SAFE_FREE(run_calc);
     //SAFE_FREE(run_calc);
     p_unicorn_counter = malloc(sizeof(struct unicorn_counter));
     p_unicorn_counter->num = 42;
     if (*run_calc) // use-after-free
        execlp("/usr/bin/id", "id", 0);
}

$ gcc test.c
$ ./a.out
Segmentation fault
$ gdb ./a.out
gdb$ r

...

0x4005ed <main+87>:	mov    eax,DWORD PTR [rax]

Stopped reason: SIGSEGV
0x00000000004005ed in main ()
gdb$ print /x $rax
$1 = 0x1



Crashes when double-free, by uncommenting 2nd SAFE_FREE(run_calc):

$ cat test.c
#include <unistd.h>
#include <stdlib.h>

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

struct unicorn_counter { int num; };

int main() {
     struct unicorn_counter* p_unicorn_counter;
     int* run_calc = malloc(sizeof(int));
     *run_calc = 0;
     SAFE_FREE(run_calc);
     SAFE_FREE(run_calc); // double-free
     p_unicorn_counter = malloc(sizeof(struct unicorn_counter));
     p_unicorn_counter->num = 42;
     if (*run_calc) execlp("/usr/bin/id", "id", 0);
}

$ gcc test.c
$ gdb ./a.out
gdb$ r

...

0x7ffff7aad614 <__GI___libc_free+20>:	mov    rax,QWORD PTR [rdi-0x8]

Stopped reason: SIGSEGV
__GI___libc_free (mem=0x1) at malloc.c:2929
warning: Source file is more recent than executable.
$ print /x $rdi
$1 = 0x1

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: use-after-free / double-free exploit mitigation

[Florian Weimer]

On 09/06/2017 02:46 PM, up201407890@alunos.dcc.fc.up.pt 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.

Thanks,
Florian

Re: use-after-free / double-free exploit mitigation

[Martin Sebor]

On 09/07/2017 10:00 AM, Florian Weimer wrote:
> On 09/06/2017 02:46 PM, up201407890@alunos.dcc.fc.up.pt 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.

Martin

Re: use-after-free / double-free exploit mitigation

[Federico Manuel Bento]

A 2017-09-10 16:41, Martin Sebor escreveu:
> On 09/09/2017 11:59 AM, Federico Manuel Bento wrote:
>>>>> On 09/06/2017 02:46 PM, up201407890@alunos.dcc.fc.up.pt 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.
>> 
>>> Martin
>> 
>> 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.
> 
> Martin

Here's the request in GCC's Bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82179

Thanks,
Federico Bento.

Re: use-after-free / double-free exploit mitigation

[Martin Sebor]

On 09/09/2017 11:59 AM, Federico Manuel Bento wrote:
>>>> On 09/06/2017 02:46 PM, up201407890@alunos.dcc.fc.up.pt 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.
>
>> Martin
>
> 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.

Martin

Re: use-after-free / double-free exploit mitigation

[Federico Manuel Bento]

>>> On 09/06/2017 02:46 PM, up201407890@alunos.dcc.fc.up.pt 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.

> Martin

Perhaps this sould be used when making use of FORTIFY_SOURCE?

Federico.