From: Martin Sebor <msebor@gmail.com>
To: Florian Weimer <fweimer@redhat.com>,
up201407890@alunos.dcc.fc.up.pt, Martin Sebor <msebor@redhat.com>
Cc: libc-alpha@sourceware.org
Subject: Re: use-after-free / double-free exploit mitigation
Date: Fri, 08 Sep 2017 12:45:00 -0000 [thread overview]
Message-ID: <d38e112f-6e2b-2e88-322f-7855c637a795@gmail.com> (raw)
In-Reply-To: <8feaa5bc-94f7-547c-c241-a82c41bd7472@redhat.com>
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
next prev parent reply other threads:[~2017-09-08 12:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-06 12:47 up201407890
2017-09-07 16:00 ` Florian Weimer
2017-09-08 12:45 ` Martin Sebor [this message]
2017-09-09 17:59 Federico Manuel Bento
2017-09-10 15:41 ` Martin Sebor
2017-09-11 15:36 ` Federico Manuel Bento
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d38e112f-6e2b-2e88-322f-7855c637a795@gmail.com \
--to=msebor@gmail.com \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=msebor@redhat.com \
--cc=up201407890@alunos.dcc.fc.up.pt \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).