From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32675 invoked by alias); 16 Aug 2016 16:28:02 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 32660 invoked by uid 89); 16 Aug 2016 16:28:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=compromise, exploiting, vulnerability, Hx-languages-length:1477 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 16 Aug 2016 16:28:01 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C77524E33F; Tue, 16 Aug 2016 16:27:59 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-13.phx2.redhat.com [10.3.116.13]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7GGRwa3008398; Tue, 16 Aug 2016 12:27:59 -0400 Subject: Re: protected alloca class for malloc fallback To: Richard Biener , Aldy Hernandez References: <57A32741.7010003@redhat.com> <57A3F57F.3050509@gmail.com> <57A4A5E8.90205@redhat.com> <57A9D7E5.6090208@redhat.com> <283F73AD-B7CD-4389-908C-BBF479DF9101@gmail.com> Cc: Martin Sebor , gcc-patches From: Jeff Law Message-ID: <3f8d451d-557d-fb96-7747-dea1c6540cd4@redhat.com> Date: Tue, 16 Aug 2016 16:28:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <283F73AD-B7CD-4389-908C-BBF479DF9101@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg01201.txt.bz2 On 08/10/2016 12:33 PM, Richard Biener wrote: >>> >>> Why would you want to get rid of the alloca here? >> Do you know the range for LENGTH in the code above? > > Yes, it's a set of tree code names. > > Is it based on >> something the user could potentially control (like a variable name, >> typdef name, etc). If you don't know the length or it's possibly >> under >> >> the control of the user, then this can blow out the stack, which >> makes the code vulnerable to a stack shifting style attack by which >> further writes into the stack are actually writing into other parts >> of the stack, the heap, plt or some other location. Essentially >> this gives an >> >> attacker control over one or more stores to memory, which is often >> enough of a vulnerability to mount an attack. > > Yes, I understand that. The above is not such a case. If an > attacker can trick me into compiling (and possibly executing) his > code then things are lost anyway. No need for a fancy buffer > overflow. I think you're being rather short-sighed here. GCC is being used in ways we can't necessarily predict -- which might include compile servers, JITs, web services, etc. In those kind of environments I think you have a significantly different threat model and GCC itself becomes part of the attack surface. There's existing web sites I'm pretty sure I could compromise if I had the interest by exploiting bugs in GCC and libiberty. Jeff