From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129354 invoked by alias); 9 Sep 2017 17:59:27 -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 129337 invoked by uid 89); 9 Sep 2017 17:59:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=federico, H*F:D*pt, Hx-spam-relays-external:sk:webmail, H*RU:sk:webmail X-HELO: smtp-out1.fc.up.pt MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 09 Sep 2017 17:59:00 -0000 From: Federico Manuel Bento To: fweimer@redhat.com, msebor@redhat.com Cc: libc-alpha@sourceware.org Subject: Re: use-after-free / double-free exploit mitigation User-Agent: Roundcube Webmail/FCUP Message-ID: <986259aa319e2c3b66a6196b589a0a60@fc.up.pt> X-Sender: up201407890@fc.up.pt X-SW-Source: 2017-09/txt/msg00416.txt.bz2 >>> 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.