From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dragonfly.birch.relay.mailchannels.net (dragonfly.birch.relay.mailchannels.net [23.83.209.51]) by sourceware.org (Postfix) with ESMTPS id 749D83858D20; Fri, 14 Apr 2023 14:08:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 749D83858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id CCB4841271; Fri, 14 Apr 2023 14:08:19 +0000 (UTC) Received: from pdx1-sub0-mail-a304.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 571BC40B34; Fri, 14 Apr 2023 14:08:19 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1681481299; a=rsa-sha256; cv=none; b=WHEBrlrwb6Mk/E1QzeMpa+rP6/rRSA/6G/d0c6U1BVd+Oh2mDktADh5grTbLsm5rBvW6Ig 18Qp2aYBoFrx25waW+BEU524/omJqAZn6hvI7OA0DbV9TwJGViiOfYZMZ5GSnVggh4RxSS +CQe7sVRBFZZ0e8pbG7EF+zPXCoyEN21T4B24Bc+DgqBL9d0MyUoUw2DUwWsyFOQBZ/H0p h5LN7LmeeMfMepl4+dRHQAO4T9vZq7BHOVg5J/LBhis6xXIB3yFyfZkI892V95XjSLKPtN i9vqXzHJ0Y4bNgOPUaYY9WjCwRP0RFcpx21RODmm5ms4n4F4I5NAmQr7bxq29Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1681481299; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=CfW3tZ8it5YAdrFxZqScbTzYMNiummYVbQSq4fRlSYg=; b=y7U45dDJhlcTI3bO4yOXhnkBH7yqzIoaJpxhhpNvUIZN9rbF206os55RQLZVv3m31RSpBK 4eiq3Z0sCQhnIurPdsC67pZRU9/ya83bh3VEA5wUpMHWzmtYUQIaRFIh17Y/2390ufLThy JK4hgYbgK9Ljspi1UKggFQ7J+fCRvC5i8xW7COTJI3kx9pzDCJGBXwIBKN9dZXcwYvtqnu spN4AAyqnBAmF2+ljG56/uGoGPuHKzR6YinZ4DsPyJZVZKCF+xWnjvyHTMco9VkI/7LoTz /iMMKfwcumB2k9RISVO0nCAqx6WaTfCW1fHmAIdCtN1ml5Z1UpOUCuTgHMI0Tg== ARC-Authentication-Results: i=1; rspamd-548d6c8f77-vzljk; auth=pass smtp.auth=dreamhost smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Shade-Harbor: 70509cae40266568_1681481299632_3858784543 X-MC-Loop-Signature: 1681481299632:1629619961 X-MC-Ingress-Time: 1681481299632 Received: from pdx1-sub0-mail-a304.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.97.48.96 (trex/6.7.2); Fri, 14 Apr 2023 14:08:19 +0000 Received: from [192.168.2.12] (bras-vprn-toroon4834w-lp130-09-174-91-45-153.dsl.bell.ca [174.91.45.153]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a304.dreamhost.com (Postfix) with ESMTPSA id 4PydZp4f2Pz3X; Fri, 14 Apr 2023 07:08:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1681481298; bh=CfW3tZ8it5YAdrFxZqScbTzYMNiummYVbQSq4fRlSYg=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=tpM9+neeQP3Ix6r2Ww9nZUyRVhF15URozrFzWHHshQjqGRzrBHmvHP5Ep249VQZo9 EZCxln9IxRKpc4LgA7n8mpxzMaLL2WzU7DGNu+jjIQzFeH7KL83LClRAKK5SC8/fh5 6XOdI0St8FQ6TUFTNUrkDKtnPVtNfpC2tmg+4F54syqHQyvVNrDoIAI8zCfrN2w6K6 DLkjQavJLLWR26nsSFIDsd+8/nbSmYCC+WjboW2EEO5p8OF5s0i2wIsu7xsnzy8c47 0rmEEn0UkGqEayfmCw9wca87GDjSd/d9f5VQEZ9EXHrbYyEEReuvPqNqE4GGQ0/klp QX5Nh4/nUUyfA== Message-ID: <78f3e6a6-dec2-3aa2-d1b6-935d842add1e@gotplt.org> Date: Fri, 14 Apr 2023 10:08:17 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: Threat model for GNU Binutils Content-Language: en-US To: Richard Earnshaw , Binutils Mailing List , gdb@sourceware.org Cc: Nick Clifton References: <032c1307-c143-3f2c-0502-683d966f0257@foss.arm.com> From: Siddhesh Poyarekar In-Reply-To: <032c1307-c143-3f2c-0502-683d966f0257@foss.arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3031.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_ASCII_DIVIDERS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2023-04-14 09:12, Richard Earnshaw wrote: > OK, I think it's time to take a step back. > > If we are to have a security policy, I think we first need a threat > model.  Without it, we can't really argue about what we're trying to > protect against. > > So the attached is my initial stab at trying to write down a threat > model.  Some of this is subjective, but I'm trying to be reasonably > realistic.  Most of these threats are really quite low in comparison to > other tools and services that run on your computer. > > In practice, you then take the model and the impact/likelihood matrix > and decide what level of actions are needed for each combination - > whether it be from pre-emptive auditing through fixing bugs if found > down to do nothing.   But that's the step after we have the model agreed. > > If you can think of threats I've missed (quite likely, I haven't thought > about this for long enough), then please suggest additions. I assume you're proposing that this be added to SECURITY.md or similar? There are overlaps with what we intend for the first part of SECURITY.md. > Threat model for GNU Binutils > ============================= > > The following potential security threats have been identified in GNU > Binutils. Note that this does not mean that such a vulnerability is > known to exist. A threat model should define the nature of inputs because that makes the difference between something being considered a security threat vs being a regular bug. > Threats arising from execution of the GNU Binutils programs > ----------------------------------------------------------- > > 1) Privilege escalation. > > Nature: > A bug in the tools allows the user to gain privileges that they did not > already have. > > Likelihood: Low - tools do not run with elevated privileges, so this > would most likely involve a bug in the kernel. A more general threat is crossing of privilege boundaries, which is not only user -> root but user1 -> user2. So this won't necessarily involve kernel bugs. > Impact: Critical Impact for security issues is done on a bug by bug basis, so stating impact doesn't really make sense. > > Mitigation: None Sandboxing is the answer for everything :) > 2) Denial of service > > Nature: > A bug in the tools leads to resources in the system becoming > unavailable on a temporary or permanent basis The answer here changes based on whether the input is trusted or not. > > Likelihood: Low > > Impact: Low - tools are normally run under local user control and > not as daemons. > > Mitigation: sandboxing if access to the tools from a third party is > needed (eg a web service). > > 3) Data corruption leads to uncontrolled program execution. > > Nature: > A bug such as unconstrained buffer overflow could lead to a ROP or JOP > style attack if not fully contained. Once in control an attacker > might be able to access any file that the user running the program has > access to. Likewise. > > Likelihood: Moderate > > Impact: High > > Mitigation: sandboxing can help if an attacker has direct control > over inputs supplied to the tools or in cases where the inputs are > particularly untrustworthy, but is not practical during normal > usage. > > Threats arising from execution of output produced by GNU Binutils programs > -------------------------------------------------------------------------- > > Note for this category we explicitly exclude threats that exist in the > input files supplied to the tools and only consider threats introduced > by the tools themselves. > > 1) Incorrect generation of machine instructions leads to unintended > program behavior. > > Nature: > Many architectures have 'don't care' bits in the machine instructions. > Generally the architecture will specify the value that such bits have, > leaving room for future expansion of the instruction set. If tools do > not correctly set these bits then a program may execute correctly on > some machines, but fail on others. > > Likelihood: Low > > Impact: Moderate - this is unlikely to lead to an exploit, but might lead > to DoS in some cases. The impact in this case is context dependent, so the impact will vary based on other factors, such as whether a PoC is available, how common the vulnerable code pattern would be, etc. > > Mitigation: cross testing generated output against third-party toolchain > implementations. > > 2) Code directly generated by the tools contains a vulnerability > > Nature: > The vast majority of code output from the tools comes from the input > files supplied, but a small amount of 'glue' code might be needed in > some cases, for example to enable jumping to another function in > another part of the address space. Linkers are also sometimes asked > to inject mitigations for known CPU errata when this cannot be done > during the compilation phase. Since you've split this one out from machine instructions, there's a third category too; where binutils tools generate incorrect code for alignment of sections, sizes of sections, etc. There's also a (rare) possibility of an infrequently used instruction having incorrect opcode mapping, resulting in a bug being masked when dumped with objdump or resulting code having undefined behaviour. > > Likelihood: low > > Impact: mostly low - the amount of code generated is very small and > unlikely to involve buffers that contain risky data, so the chances of > this directly leading to a vulnerability is low. > > Mitigation: monitor for processor vendor vulnerabilities and adjust tool > code generation if needed. Sid