From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cross.elm.relay.mailchannels.net (cross.elm.relay.mailchannels.net [23.83.212.46]) by sourceware.org (Postfix) with ESMTPS id 8FB103858D20; Fri, 14 Apr 2023 18:27:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8FB103858D20 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 E5F37542809; Fri, 14 Apr 2023 18:27:02 +0000 (UTC) Received: from pdx1-sub0-mail-a305.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 61CFC5427EC; Fri, 14 Apr 2023 18:27:02 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1681496822; a=rsa-sha256; cv=none; b=VDI8I58FNAIYaldQa6/J5xIbQF72t5AQRLcee6bbtNUatc8MvOSTL9tsDuPlmVBqfU7tKb /Zal3Wb0zR4JlXoeSsPagtbQOXsaN3d/cEebGwFc2xm6Gv2t+qcQJsRM+9YabePprSkOCS p61glQK5IUHVC6ooDAdhJZYfgL6VNrR+04eyYXCyPqdhvQV89R8Md7dsmeGKmH389PY8jE vG3dLarNJEDxcsnRGifqQhp/s/mg0QjVn5f8IUMN6nAmn+1+WjC0EIAx8GVapzkvZGu48i C2NzyET5zrvi8cmY5FrT6BN27kP8BcBrDa1Mtelr9waQPFSCIwEdqMfraIz37A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1681496822; 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=d7/RtdBV9OXnTad/yVTuP1O8bkNY8prvK0P8JJw3itI=; b=KgI+oGgoJr3xkWsw7kLvsW/VHrqBpMLhgxnuvvF9Ug3xp8BpoDWgxw1MGcRrxQck9anwc5 rLQs0Ppg7M+RfXbrOuGkpXQb8Fa3TaQRLpmHOM+3sEl81UBoFSJB74ijkg3Us3QvkAlv0i jjAr8lBaH5WxbhwqzU9eZ/CK0ikYIIabse5CfHUfDEa2Arw59MmkCM4ckkLurMEfIq1ksK pWwN96NTJKGVNtFNE5m1ko2/iUL6ZgbsJ7t4+mqmz0q9SYLsR2ur/Bfx2QoKnZff/KTqbN JJHoaaELwUl/tlPl51OOnBsYM8Dv+BKls/z5iuwUbPEz4xttFXW1nqi0LSVYTQ== ARC-Authentication-Results: i=1; rspamd-7f66b7b68c-fvcrx; 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-Print-Abaft: 323ac75c6fa8b80b_1681496822694_4086244304 X-MC-Loop-Signature: 1681496822694:432437488 X-MC-Ingress-Time: 1681496822694 Received: from pdx1-sub0-mail-a305.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.116.105.172 (trex/6.7.2); Fri, 14 Apr 2023 18:27:02 +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-a305.dreamhost.com (Postfix) with ESMTPSA id 4PylKK59XgzCS; Fri, 14 Apr 2023 11:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1681496822; bh=d7/RtdBV9OXnTad/yVTuP1O8bkNY8prvK0P8JJw3itI=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=J3Otsm6aypd12rFNQfC12TBlarEpPuwhdTslizPp6CqEEDQqstWLLt283T2Tb23u2 dYcBQKfn6zVenhUtrN3JFcQdWZIrKMrDE2yS6ijnLfjx9fDqRDc+dXFX0jvPtnsHqO mW+IQ4jzukFRz5Yrtr8DmyVmRAqmUklJuZTDHdWovV8CK+bTIiBOAC5rZZmtEGTgFl IgYAISHpaqlY8M9QfngFJCv0/1Z/onSaXRcfNGWpp9oCdy4SKTUWaz1qQjWDnOwkGO xIDHk/QUGTRKS+Vy1EB/C5vVa7JAMGIkLID9HhLx7ucP7ft58u5ZIk08dH+R4DQVxW /4HB/D3MiF0oQ== Message-ID: <20dbbe16-c7e5-412e-0506-2118dfef5fc2@gotplt.org> Date: Fri, 14 Apr 2023 14:27:00 -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: RFC: Adding a SECURITY.md document to the Binutils Content-Language: en-US To: Ian Lance Taylor Cc: Paul Koning , Richard Earnshaw , Nick Clifton , Binutils , "gdb@sourceware.org" References: <1c38b926-e003-0e21-e7f1-3d5dbec2aabf@redhat.com> <5d044987-39eb-a060-1b2b-9d07b1515e7d@gotplt.org> <73bc480a-a927-2773-8756-50350f76dfbf@gotplt.org> <4ed86e65-0b7f-11d4-8061-2c5d0b1e147e@foss.arm.com> <7b6b10f8-e480-8efa-fbb8-4fc4bf2cf356@gotplt.org> <0224757b-6b17-f82d-c0bf-c36042489f5e@foss.arm.com> <01e846c0-c6bf-defe-0563-1ed6309b7038@gotplt.org> <2d4c7f13-8a35-3ce5-1f90-ce849a690e66@foss.arm.com> <01b8e177-abfd-549e-768f-1995cab5c81d@gotplt.org> <96e2ec59-11c6-329e-18c4-bf284eb752ac@gotplt.org> From: Siddhesh Poyarekar In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3028.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,MEDICAL_SUBJECT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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 13:37, Ian Lance Taylor wrote: > On Thu, Apr 13, 2023 at 10:01 AM Siddhesh Poyarekar wrote: >> >> On 2023-04-13 12:49, Paul Koning wrote: >>> If someone sends me an executable file, and I execute it and suffer a virus, shame on me. If someone sends me a C source file and I compile and link that BUT DO NOT EXECUTE the resulting executable, and I suffer a virus, shame on the tool. >> >> If someone sends me a C source file and I compile and link it without >> inspecting it first, then definitely shame on me again. Compilers and >> linkers assume *trusted* input. > > I profoundly disagree with this. I should reiterate that this is not about robustness, it is about treatment of bugs as security issues, i.e. by assigning CVEs and sending out advisories to the larger user community. I am not arguing against fixing bugs at all. > Compilers and linkers must behave in a reasonable manner when given > untrusted input. Behaving reasonably can of course include failing > with an error message like "program too large", but they must not dump > core and they must not use up all available memory. They very much > must not have a buffer overflow during compilation that causes them to > execute arbitrary code. Users should not be expected to run compilers A compiler crash, core dump, etc. is definitely a serious bug and we consider them as P1/P2 in almost all cases. However to be considered a security issue, the input has to be crafted and that's where the user comes in; their responsibility is to ensure that they don't build untrusted code (e.g. when they're trying to study malware or virus sources or binaries) outside of sandboxes. The expectation is *not* that they always run compilers in a sandbox, it is that they're aware of the code they're trying to compile and IMO it is not an unreasonable expectation. The odds of even minimally trusted code (like an upstream project) resulting in, e.g. overwriting or corrupting some persistent state (like some file on disk) or sending out private information due to a buffer overflow in gcc, ld, or even objdump is near-zero. The code would have to be specially *crafted* (or the operator being remarkably unlucky) to achieve that. If as a project we decide to treat untrusted input as a valid use case, it is going to shift the goalposts for binutils (and gcc, if we take the same stand there). I suppose golang does try to adhere to these higher standards somewhat but I am not well versed with their formal position on this. I've seen them consider bugs due to untrusted regex inputs as security issues whereas even glibc currently doesn't, except for some very specific conditions. The llvm project doesn't consider anything[1] a security issue at the moment. I was told off-hand by a rust maintainer that the rust community also pretty much aligns with the llvm position, but I don't have a handy reference for it. If binutils, gcc, etc. aspire to the levels of support that golang provides, we need to do what the llvm community is currently doing, i.e. form a security group and incrementally identify parts that we want to identify as security sensitive and provide stronger security guarantees for them. My previous suggestion to do that was discouraged[2], so if that has changed today then we could move in that direction. > and linkers in a security sandbox (though it would be acceptable for a > compiler to set up its own security sandbox if that seems useful). I suggested an --isolate flag for the analysis tools (objdump, etc.) to do exactly this elsewhere in this thread. Thanks, Sid [1] https://llvm.org/docs/Security.html#what-is-considered-a-security-issue [2] https://inbox.sourceware.org/binutils/YBD72RqjVomppMYS@vapier/