From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126962 invoked by alias); 10 Sep 2017 15:41:10 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 126951 invoked by uid 89); 10 Sep 2017 15:41:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=malcolm, Malcolm, H*Ad:U*msebor, Hx-languages-length:1539 X-HELO: mx1.redhat.com DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E719CAC614 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=msebor@redhat.com Subject: Re: use-after-free / double-free exploit mitigation To: Federico Manuel Bento , fweimer@redhat.com References: <986259aa319e2c3b66a6196b589a0a60@fc.up.pt> Cc: libc-alpha@sourceware.org From: Martin Sebor Message-ID: <861608b3-d303-ecef-ef7c-87bc7c490aab@redhat.com> Date: Sun, 10 Sep 2017 15:41:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <986259aa319e2c3b66a6196b589a0a60@fc.up.pt> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2017-09/txt/msg00423.txt.bz2 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