From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48270 invoked by alias); 20 Apr 2018 21:36:26 -0000 Mailing-List: contact libc-help-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: libc-help-owner@sourceware.org Received: (qmail 47305 invoked by uid 89); 20 Apr 2018 21:36:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=3.3 required=5.0 tests=AWL,BAYES_00,BODY_8BITS,FREEMAIL_FROM,FROM_EXCESS_BASE64,GARBLED_BODY,SPF_NEUTRAL autolearn=no version=3.3.2 spammy=H*Ad:U*libc-help, overflows, HContent-Transfer-Encoding:8bit, protect X-HELO: popelka.ms.mff.cuni.cz Received: from popelka.ms.mff.cuni.cz (HELO popelka.ms.mff.cuni.cz) (195.113.20.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 20 Apr 2018 21:36:23 +0000 Received: from domone.kolej.mff.cuni.cz (popelka.ms.mff.cuni.cz [195.113.20.131]) by popelka.ms.mff.cuni.cz (Postfix) with ESMTPS id B7BAD499C4; Fri, 20 Apr 2018 23:36:18 +0200 (CEST) Received: by domone.kolej.mff.cuni.cz (Postfix, from userid 1000) id 7B65B5F7CF; Fri, 20 Apr 2018 23:36:18 +0200 (CEST) Date: Fri, 20 Apr 2018 21:36:00 -0000 From: =?utf-8?B?T25kxZllaiBCw61sa2E=?= To: =?utf-8?B?5riF5rC056WQ5aSq6YOO?= Cc: "libc-help@sourceware.org" Subject: Re: malloc/free: tcache security patch Message-ID: <20180420213618.GA12494@domone> References: <20180420124408.3C16F10E8052@mail.shift-crops.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180420124408.3C16F10E8052@mail.shift-crops.net> User-Agent: Mutt/1.5.20 (2009-06-14) X-SW-Source: 2018-04/txt/msg00015.txt.bz2 On Fri, Apr 20, 2018 at 09:44:10PM +0900, 清水祐太郎 wrote: > Hello > > I'm Yutaro Shimizu (ShiftCrops). > > I want to patch malloc.c. > The mechanism of tcache is very similar to fastbins. > However, I can malloc from arbitrary addresses by tampering the tcache_entry. > That's because there is no chunk verification process. > I think it is an important security issue. > This was discussed recently, search archives. In short malloc check don't protect you and can't protect you. This patch only makes malloc slower for false sense of security. Attacker could use buffer overflow in lot of ways before its freed. Also attacker could with some effort examine check and fake data structure to make check pass. These are mainly used as tool to debug malloc implementation. That they sometimes serve as poor's man valgrind is secondary. You should use valgrind to find and fix buffer overflows in first place.