From patchwork Fri Feb 23 12:17:34 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Francois Goichon X-Patchwork-Id: 877051 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=sourceware.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=libc-alpha-return-90530-incoming=patchwork.ozlabs.org@sourceware.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="gyRPHSxi"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3znqx657WQz9sW7 for ; Fri, 23 Feb 2018 23:17:46 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:from:subject:message-id:date:mime-version :content-type:content-transfer-encoding; q=dns; s=default; b=wOO z0qILtjxpt8C8bYa2gTqlaVoz1590UdkeFxjxgz1OOSor+XXs81Ecy+4jf1ylLeP od3nYEJ7SX6JE5BnjFONFgxREPxdmOHwTbdg+7I9/K1mwj8Hy/kH85exUURTZEaa njHu3dO/Qi2hmgCtgFDhCwehRB2N+VXfCqfebSsY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:from:subject:message-id:date:mime-version :content-type:content-transfer-encoding; s=default; bh=6Y498SWpb f8dZCSuuTXddLiT0I4=; b=gyRPHSxiUxxeZJGivckcePG6ZfNcpyTNccQJ1Ncoz Tj1ZTwiCTExg5sURWF7G4MlAUqgmaSGYA2cEhGM910NbzFoGf1JO9ijjPc7reZFa IoTMNThkCdXhXjB/jLtTPuihsy+JoZvD5Fe1IRTODYrx++up0ybZLPyCHYpWwAjO 5w= Received: (qmail 36835 invoked by alias); 23 Feb 2018 12:17:41 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 36824 invoked by uid 89); 23 Feb 2018 12:17:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*p:D*google.com, victim, H*MI:google, H*M:google X-HELO: mail-wm0-f66.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=O8lshCoV39/IY4jGuM7VdO3zmwEVKlPJ14BaUpGMXM0=; b=Q/vBoKusVg2KuXW1dN2C7YUR17fazZbjPgYEVZv9k52Jt92pJy5Xw1yol6HtUvKcEt taDAWP6SbYJKqa2tdJZfnfKXXlcGen/EW5T8wQg0wVW8fI6a3dCQfQff6FG8Qr3s2lVL VzsFKBVaiIKQD6aKUMrgzAGy8Wj6B3oKX4QItUbefVX6P41qAPO/+lAkME5bu1YKHevb CeRt7ToWad/piV4LvxMPR2qv0N9T/VPhbi5LKnjoJfKBdZj9XODBuC6OuZhai7EP/Z5/ ifqu/d+lBiQ5H3x9J8ovQTtlMMMbFmpOCpaZSvc7+4pGW8TGCrCdz14xs7qVGQ0Lss0T IGcA== X-Gm-Message-State: APf1xPAZ1dYnCypR1Kn48I1+q9G51p/onpdwpubnnN7VBaCOdeWnv7U8 rbmeKebYLw6uvqQotBF7FCD6skNKz24= X-Google-Smtp-Source: AH8x2264LPXpOx3Df/YvirvO/kLHzMHmelklnU5evdoLe8U9B52Ljp7dt/Qo4mcq5MvOiuY4ERuJQw== X-Received: by 10.80.161.135 with SMTP id 7mr2545709edk.241.1519388257015; Fri, 23 Feb 2018 04:17:37 -0800 (PST) To: libc-alpha@sourceware.org From: Francois Goichon Subject: [PATCH] malloc: harden removal from unsorted list Message-ID: <9b74b50e-66a6-3321-5668-d89b35a21cd8@google.com> Date: Fri, 23 Feb 2018 12:17:34 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 There isn't any linked list check when getting chunks out of the unsorted list which allows an attacker to write &av->top (unsorted_chunks chunk) almost anywhere (e.g. into a bin of their choosing to get it out in a subsequent allocation), with a relatively simple corruption: --- // Initial state long * c = malloc(0x100); malloc(0x100); free(c); // Corruption: point c->bk to bin used in alloc after next c[1] += (0x110 >> 4)*8*2 - 8; malloc(0x100); c = malloc(0x100); // &av->top -- Controlling bins is likely to be enough to gain code execution by overwriting farther ahead in .data or .bss (e.g. __free_hook). Tested on i386 and x86_64. * malloc/malloc.c (_int_malloc): Added check before removing from unsorted list. --- malloc/malloc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/malloc/malloc.c b/malloc/malloc.c index 58f9acd4d1..17d373eca9 100644 --- a/malloc/malloc.c +++ b/malloc/malloc.c @@ -3775,6 +3775,8 @@ _int_malloc (mstate av, size_t bytes) } /* remove from unsorted list */ + if (__glibc_unlikely (bck->fd != victim)) + malloc_printerr ("malloc(): corrupted unsorted chunks"); unsorted_chunks (av)->bk = bck; bck->fd = unsorted_chunks (av); @@ -3941,7 +3943,7 @@ _int_malloc (mstate av, size_t bytes) bck = unsorted_chunks (av); fwd = bck->fd; if (__glibc_unlikely (fwd->bk != bck)) - malloc_printerr ("malloc(): corrupted unsorted chunks"); + malloc_printerr ("malloc(): corrupted unsorted chunks 2"); remainder->bk = bck; remainder->fd = fwd; bck->fd = remainder; @@ -4045,7 +4047,7 @@ _int_malloc (mstate av, size_t bytes) bck = unsorted_chunks (av); fwd = bck->fd; if (__glibc_unlikely (fwd->bk != bck)) - malloc_printerr ("malloc(): corrupted unsorted chunks 2"); + malloc_printerr ("malloc(): corrupted unsorted chunks 3"); remainder->bk = bck; remainder->fd = fwd; bck->fd = remainder;