From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id uUoGNdcoOGST0CoAWB0awg (envelope-from ) for ; Thu, 13 Apr 2023 12:07:51 -0400 Received: by simark.ca (Postfix, from userid 112) id CCE131E221; Thu, 13 Apr 2023 12:07:51 -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=dfSfpGyD; 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=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_MED,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 79AAE1E110 for ; Thu, 13 Apr 2023 12:07:51 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0A0B33858430 for ; Thu, 13 Apr 2023 16:07:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0A0B33858430 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1681402071; bh=NSfz+P3ij9TXycROQ6nu3JJ+QN0UNN3vTeZrFo8/liQ=; 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=dfSfpGyDK6hv6XqTg2elqammZoJsWv9d6BcYLS0+I0j05JtgwMoWWGWRFEaMGbr4y e2zBkH+z+XMz6ZqWG2Zw4rG3Q0Sjb6Htbjd6Dy1oJaefaFHlly9WyjtBWBRC9cq4MT CDUHwNOhaO1g1AAgpNLB9MiYptAGkmO1NtIk0Egg= Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 3CC7C3858D39; Thu, 13 Apr 2023 16:06:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3CC7C3858D39 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 7E9F5D75; Thu, 13 Apr 2023 09:07:10 -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 3B7DD3F6C4; Thu, 13 Apr 2023 09:06:25 -0700 (PDT) Message-ID: <54528386-cb90-eb52-e5c8-c659be5217d5@foss.arm.com> Date: Thu, 13 Apr 2023 17:06: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: Paul Koning , Siddhesh Poyarekar Cc: Nick Clifton , Binutils , "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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 16:08, Paul Koning wrote: > > >> On Apr 13, 2023, at 11:02 AM, Siddhesh Poyarekar wrote: >> >> On 2023-04-13 10:50, Richard Earnshaw wrote: >>> No, whilst elf can be executed, objdump should never be doing that: it's a tool for examining a file, not running it. You have to have a tool that can safely examine the contents of an elf file or you can never verify it for issues - opening it up in emacs to examine the contents is not the way to do that :) >> >> You can verify it for issues, in a sandbox. >> >>> 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. > > No. Buffer overruns are generally recognized as security issues, precisely because they (often) can be used to produce arbitrary code execution exploits. > > A buiffer overrun would be merely a robustness issue if it is guaranteed to cause nothing worse than a program abort. > > paul > Thank you Paul, you put that better than I did. So lets try to come up with a more robust taxonomy... A script file is a file that contains plain text that might be fully viewed in a traditional text editor. For binutils there are three scenarios: 1) Tools that examine the contents of some non-script files and dump a textual representation of their contents (primarily to stdout). 2) Tools that process the contents of files and create new files based on them 3) Tools that might try to 'execute' the contents of a non-script file. Binutils really only has tools in classes 1 and 2. For scenario one, only files specified on the command line as output files should be written to (or otherwise modified). Script files are not processed. Tools that fit into this category include nm, objdump and readelf. For scenario two, only files specified on the command line or in script files as output files should be written to (or otherwise modified). Tools here include 'as', 'ar', objcopy, ld. Temporary files may be generated (in a secure manner) as part of the process of doing this. For scenario three a non-script file might be executed, but I think that there are no tools in binutils that need to do this. Given the above, a security issue would exist in a tool if it could be made to violate the constraints on the scenario specified for the tool. R.