From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dormouse.elm.relay.mailchannels.net (dormouse.elm.relay.mailchannels.net [23.83.212.50]) by sourceware.org (Postfix) with ESMTPS id C56263858C53; Mon, 17 Apr 2023 16:17:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C56263858C53 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 B5BC876125E; Mon, 17 Apr 2023 16:17:08 +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 37732761222; Mon, 17 Apr 2023 16:17:08 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1681748228; a=rsa-sha256; cv=none; b=pV13u1Lr7Iv5Tv1o27aA1FDtDi9Np0yl0ToJ0V+0DZdH3Sybm/1Uy87GkOso4VM5pJBuxj 4/j5dD8tQUxhf5bt3OCL6q/u8E7CG+JayPz72mL7F7i/wwK3CResqKyvpBBwb0/FcToLQa WavQWnpx0IaN5M/tV8mKJqofzMLZ9BAsNpaqA4ncqusFopiiWCN87Ktf9yldK9pV1Hx3bm 3l8zt+FLRzqMwhb4wIAsDUpXv4mxhsNBDMqvyVnliMBzZNp7T+2RHikHMLUrU2B97sz7V4 vaSWE66B21uHq7gO+P9I/Y/39vi6OnWGx0XDPyuJ3OIEDYFIk2FoCoKHk7/bsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1681748228; 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=JNh8vSZwNELsxdfGvZ9s1FPs84bGqnJuGBWp/RVB0AY=; b=lHWSClCJ3+rh+fXYdJaCRk4qSb5TsMkKNEpQNMVE4biVWMeX4KDi3mIrsuoSmbjIGZAYre +HsG+NT+Ux1CxFZAN4eYqE5hyTLSZHEC83gw6dHAzD9AyCWN7H28n4rof4IXB1vxX21lId Dx3TK4B2F9vlWvNxip5BuClKBTT1zk4hLn9zof+veJGDxsyJVE+lBW9kXSezIyGaQ9MXo/ qvCOyVLjeANNUblXZ/1id1hU1rGmKeKH0ucQu3BYwIrXwIU9J4Cyavv+v1VPl3h6/q3pw9 FpXs5IIE+4VQqfXZZsCLD02uW7jfB1QHp5Jqwg7dOQZX09c8b0lcspEUcJDIrw== ARC-Authentication-Results: i=1; rspamd-7f66b7b68c-m6mff; 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-Bottle-Grain: 2f332f7b15d08e1d_1681748228515_693614382 X-MC-Loop-Signature: 1681748228515:1594434450 X-MC-Ingress-Time: 1681748228515 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.116.217.224 (trex/6.7.2); Mon, 17 Apr 2023 16:17:08 +0000 Received: from [192.168.2.12] (bras-vprn-toroon4834w-lp130-09-174-91-45-80.dsl.bell.ca [174.91.45.80]) (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 4Q0XJ33zJxz30; Mon, 17 Apr 2023 09:17:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1681748228; bh=JNh8vSZwNELsxdfGvZ9s1FPs84bGqnJuGBWp/RVB0AY=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=Wl7cRGPRTEpz7+EzwV4ApaAaRe2OSlD7+tA3OjJ1e34pZryJk8XWUo7kw/MZ9+ulD EScChJAOglIc5c4f2POcKygkKsblyOBH/YQmgHfSVEL3eWV1lAFPlNlLmigmo961kM SRBRfnlUXkPR5JbIOhdfX4MNd7E3AQZFdjeL3HwTi6+bSd+21UNJjkvcP3qZxrEXg0 MdpGcQ9ykAn9wi/URthARm2hPqpQ5g73H+84zVsbfQDxigazKGyDy5pvv1VHqIKbdq fPu7ZSbWflVEnRb+s7T3kHbq69IaQakE1l00I+DVv3NSdA0ZkkKQBWlpRMluRIKck+ U2XZp1nS22OJw== Message-ID: <1a4953e1-7c23-79be-9d4e-249f49f48ff0@gotplt.org> Date: Mon, 17 Apr 2023 12:17:06 -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> <78f3e6a6-dec2-3aa2-d1b6-935d842add1e@gotplt.org> <5947697c-274f-58a7-af02-00618691021d@foss.arm.com> From: Siddhesh Poyarekar In-Reply-To: <5947697c-274f-58a7-af02-00618691021d@foss.arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3031.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 10:41, Richard Earnshaw wrote: >>>   Impact: Critical >> >> Impact for security issues is done on a bug by bug basis, so stating >> impact doesn't really make sense > > On the contrary, the point is to estimate the risks and the scale of the > potential damage if such a bug were to exist; this can then be used to > determine how much pre-emptive work is needed to guard against it. > Saying that we won't consider it until it happens is not helpful. Then this needs text describing the context under which this impact is rated and clearly dissociating itself from CVE ratings because given the current state of CVE assignment, bots will assign whatever rating we put here regardless of the actual nature of the flaw. >>>   Mitigation: None >> >> Sandboxing is the answer for everything :) > > This threat is about the ability to escape a sandbox (eg linux user > accounts are a sandbox of sorts).  So putting something in a sandbox if > you can escape it is pointless.  Furthermore, if a bug of this nature > exists in the tools then it doesn't need a remote actor, potentially a > malicious user on the machine can exploit it to access things they are > not supposed to in the standard system security model. They're two different CWEs, one is CWE-693 (Protection mechanism failure) and another CWE-269 (Improper Privilege Management). There are others, like CWE-648 or CWE-271 that may be relevant if you want to break this threat down. >> >>> 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. > > Not necessarily.  If the bug could bring down the machine then it's down > to whether the user is trusted or not.  Admittedly, there are probably > plenty of ways to do this without needing binutils, but that's beyond > the scope of this discussion. It is within scope, because binutils ships libbfd, libopcodes, etc. that other applications may link against. Depending on their usage context, the nature of input will make a significant difference on how to treat a DoS. >>>   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. > > Generally speaking it's just a matter of work to get from a known buffer > overrun to a PoC that shows an exploit, if the input is not trusted. The > chances of a normal buffer overrun that is not done with malicious > intent leading to a security issue directly is incredibly low. I was referring specifically to what currently is the accepted industry standard for rating CVEs, to help vendors determine how urgently they need to fix a bug, i.e. within days or within weeks. See the CVSSv3 calculator[1] as an example of how one would rate CVEs. Please note though, that security teams of different projects/vendors tend to put their own subjective sauce over these ratings that make the ratings more specific. This is why a vendor rating[2] may be different from the rating of, e.g. NVD. >> >>> >>>   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. >> > > Well I did say that I might have missed some additional threats, this is > a WIP :) > > If you think additional cases need to be added, then go ahead. The text doesn't take into consideration the fact that binutils ships libraries as well and that they could be used in a context independent manner, meaning that their threat model will depend on the definition of how we support using those libraries. This means definition of the contexts under which these libraries are supported for usage, unless we want to support any and all kinds of use. The glibc security exceptions[3] are a good example of how this is typically done. Thanks, Sid [1] https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator [2] https://access.redhat.com/security/updates/classification [3] https://sourceware.org/glibc/wiki/Security%20Exceptions