From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from boar.tulip.relay.mailchannels.net (boar.tulip.relay.mailchannels.net [23.83.218.250]) by sourceware.org (Postfix) with ESMTPS id 7F3783858425; Fri, 14 Apr 2023 12:43:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7F3783858425 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 F1CC38C1982; Fri, 14 Apr 2023 12:43:33 +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 7A6398C25C6; Fri, 14 Apr 2023 12:43:33 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1681476213; a=rsa-sha256; cv=none; b=TId66X1YYl/cfRvaau5vEXzY5G8D/MPTB7PbUioYXraCO/ZVjMmEmqrOuCQVXpu8FRb+yY VFmj2+vGo10ldw02dRBz2iRwxlvNDV0kWt0beWRGtOWji5MzWpzn2yqw8b4SQbxt9K000R I1fRhZuD7FuUkJY56xpPBawDFQBIBBn/xaOUG0Gqj3QrMRiiJCEJMWFRXTG6zg0KalBlFI a8UDkXZ5ZVQtwirQHN4O+aTLplyST9bBOy3ZYwmPJkfDeT5MLFiiqYF+DFP0sPwuagbI5d JiB20QdtPYnPINZQwa/ivT/7NDifx4h4/YcENX/ww/EjDO2PZBbs2oVVLVWWOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1681476213; 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=eTmFh1sTa/0A1laRrP9DpBxbbIu5cL3WSdDVtoy1WHQ=; b=oumtiJ116+tn/8IZeGnC4ch94OXJT2fTp9jn6x2VwnCtG580hHb6e2Qj2OgCEbMT1Ot2Dg dGYmkXfbHmOt6QeLCjpIeyz4q/qXbeNdwVhlVCB+INgS6gBMH+3ojvwMtAcKJTHMF1G0Ev mCrOKYBqMTpUKCFBtIcklRLbponKBOnleRVSDJlf+fJP8MTJahRmS7wRwbL+MumcaOFL3O ePkHJoKA3bi1mZeCSTWqrsx7cNG3XfBpGpcus1tB9B11xZu+oKk8ISiJipbpQdYoIbavPq i7gklsids3SQsPB0H1/A7CANDnGoQpraKXHnMgwprGlroa2syNReL8ZTY6Gdtw== ARC-Authentication-Results: i=1; rspamd-548d6c8f77-d8k59; 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-Cold-Well-Made: 758d5e2b6ed7a2da_1681476213764_3714261514 X-MC-Loop-Signature: 1681476213764:3065137766 X-MC-Ingress-Time: 1681476213764 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.125.42.190 (trex/6.7.2); Fri, 14 Apr 2023 12:43:33 +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 4Pybj06zTvzXK; Fri, 14 Apr 2023 05:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1681476213; bh=eTmFh1sTa/0A1laRrP9DpBxbbIu5cL3WSdDVtoy1WHQ=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=o8vBccBsREAHWBCZuXZantP2GjR/oeWIfFVgfraxaKdqWuiXNwENWOjJZ38yAfPXX ny/9n5UBgxVk8qbI4mN4LN2viD+INunLkwHpKMXMB8Ou2LYuIKbcnIAOxKNZpqJkGr O4h8PKHxnmRVbaSg/e9cnjyzAa7yYhPnavRRSnVHn9mEnFCrPSZLLP5fkyOja044jy 26V2UEz519/YYGcfpI1zjSmG5aiGRrHF9UwhrBEW//T5YdcW59IwKFSsq7XzrAiWmE iDE2HHMxNcAEWzD74tGj6ezRt6Cr+hM4hMPXADFsgA/E5ycsAFyJh8r2O8vwZrmtEd ZS+iOwbZmS3Kg== Message-ID: Date: Fri, 14 Apr 2023 08:43:31 -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: Richard Earnshaw , Nick Clifton , Binutils Cc: "gdb@sourceware.org" References: <1c38b926-e003-0e21-e7f1-3d5dbec2aabf@redhat.com> <5b147005-bd28-4cf9-b9e7-479ef02cb1ad@foss.arm.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> <43912382-2d32-9fff-8dad-5c41491eb804@foss.arm.com> <613a6e55-846c-9f1f-cfd0-046b52487ae3@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.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MEDICAL_SUBJECT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,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 05:52, Richard Earnshaw wrote: >> You don't analyze untrusted data outside of a sandbox.  Really, it's >> security 101. > > I think your definition of trusted and untrusted must vary from mine. > And I think your expectations on users is somewhat unreasonable. > > In my book any binary object obtained from the internet is /potentially/ > untrusted.  That includes any object file that is downloaded from, say, > a Red Hat server in an RPM package (even if it's been signed).  Are you > seriously suggesting that every user should deal with every file as > though it was completely untrustworthy? You're the one who's saying that you don't trust binary objects obtained from signed packages even after verifying the signatures, not me :) The term "untrusted" has a fairly clear meaning in this context; it is one that is obtained from an unfamiliar source that is cryptographically signed (that you can verify) as being valid. Binaries on your system and/or those that your distribution provides are deemed trusted because you verify keys at various stages to reinforce your trust in the contents. Binaries that people send for bug reports are *not* trusted unless the medium they used to send the binaries (e.g. private bug reporting tool where only verified users get to post) is trusted or the user is trusted (through a verified/signed email). >>>>> But all that is beside the point.  The original case I gave was a >>>>> /corrupt/ elf file that caused a buffer overrun in the objdump binary. >>>> >>>> ... and that's a robustness issue.  Any buffer overrun in any >>>> program could in theory be exploited to send out files. >>>> >>> >>> So what's your point?  These /are/ vulnerabilities in the program and >>> need to be considered security issues. >> >> I already made my point; I agree that they are security issues but the >> security mitigation mechanism is in the environment, not the program. >> I do not think it is in the interest of the binutils project to >> guarantee safety in analysis of untrusted programs without requisite >> protections of the environment. >> >> Sid > > Any buffer overflow where the data used to do the overflow comes from an > object file is a potential breach, unless the program can detect this > and make a controlled abort before any possible break-out can occur. > > The key here is defence in depth.  It's not enough to say that > everything must be done in a sandbox, even if that is advisable. They key is in what a project can feasibly guarantee and IMO the binutils project is not in a position to guarantee this level of security. By putting this into SECURITY.md, we'll be signing ourselves (and downstream maintainers) up for much more than they can handle. If the goal for being able to safely analyze untrusted binaries without sandboxing is desirable then the project needs to invest resources to making it happen, not make a promise first and then look for those resources. Sid