From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cyan.elm.relay.mailchannels.net (cyan.elm.relay.mailchannels.net [23.83.212.47]) by sourceware.org (Postfix) with ESMTPS id 74D9B3858D20; Thu, 13 Apr 2023 17:29:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 74D9B3858D20 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 8EF24821CD1; Thu, 13 Apr 2023 17:29:15 +0000 (UTC) Received: from pdx1-sub0-mail-a307.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 0AE52825164; Thu, 13 Apr 2023 17:29:15 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1681406955; a=rsa-sha256; cv=none; b=ZwbmcvhN0DwQXgu+xAqxL/Tw6nRXgUvtNrru0guKlyIZQWYMyu3Uh/oOkIZ5mPBpjaoRog /NJKoNbvl+tUeqzQ4I7syJBs3bul33iP9FC8j8/v9TDe+7rdcavlWw5NChXoX5mngDPUml zIhvlUlrMBH553NxW/XkWt3Q+pulyXvUGT01Bus2b/ZTzVDO98kK4POvOUwCFjYlws9HF/ X9Nv3kdyE4aTpWtCfIoDZX6KKFaoJkP+77/HHly1g2RXdScBlsNmg9uHq1C5o/xojeMruX 0E26irPQg4RyV2bQKIVeTFUcWnei41BKWnqak7iTf7jGkV/Iw2Tel/hoFQ5b6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1681406955; 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=SHLsnERtISjeSlwv6FJCaLA2gIsLTq1gGZXorF1jkN0=; b=LqcluapFZNec/ZiC9DiV+zJ/MpJPhfVILXXs3UPghScMhGJsjIuiRAipH4GTwTcmvD+lFe AgHMtHrMbcCyUYS/xGtIUQ2qIOVBCt9id0TkUs2XLaM6vTI0Bf0PjeXxnrUjNhhhhYT62X eu6/XYBfiBv79bamoTkHXypHjGWgontgNaFqF9gzQeHBLe8RvMgfS5mwg+CE0Pw9KnEA3O Eo4KztUnRMbOlF9BBUBmBVdZHVgoYPtwrqwG1izB/Uy/Wa7ThqPqWuYqqs6bLLtPuCprVm j/q7oPNUoSnXzF/h12yKzGdcl3I1vwTsRum/K3hfYkwaaOPZX12Yz+TsZp8lRQ== ARC-Authentication-Results: i=1; rspamd-548d6c8f77-xdp5r; 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-Broad-Thread: 635d0e1325439a8e_1681406955333_1866209242 X-MC-Loop-Signature: 1681406955333:778638575 X-MC-Ingress-Time: 1681406955333 Received: from pdx1-sub0-mail-a307.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.98.219.208 (trex/6.7.2); Thu, 13 Apr 2023 17:29:15 +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-a307.dreamhost.com (Postfix) with ESMTPSA id 4Py656346mz5k; Thu, 13 Apr 2023 10:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1681406954; bh=SHLsnERtISjeSlwv6FJCaLA2gIsLTq1gGZXorF1jkN0=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=kZRXXmAuYYS5j+4B/nK9fFcIXZzbAemB4VTBgFDwjz3MnCcbbSJbYwudCXFqRKuKC 2Mo3Owt30lgdXnG7a8T7HyGWAYDbn+5jL1EcxkqhugLJEdwR/v/8ZHkZaJzbccwQH7 Dqa3ZKpFV1y+M6Jmx91ERbdTuw71PPK4/6kn7s83UUYWu++QVtWFHpTpvxfDowpzgy jN4I/yIXVrb8FLTZ7VzJ7VnChZUISH/+tAUha1e54S80DQLg0B2pMgPvGADAFEqQ0U Ay2xEt4qYC/sb4Ur2L7eJzuWWvit16AQoewH98GMvdxdg3qCgrkaEPZDyvEGuZgGEB VqVIRXdaQscmA== Message-ID: Date: Thu, 13 Apr 2023 13:29:13 -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: Paul Koning Cc: Richard Earnshaw , Nick Clifton , Binutils , "gdb@sourceware.org" References: <1c38b926-e003-0e21-e7f1-3d5dbec2aabf@redhat.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> <96e2ec59-11c6-329e-18c4-bf284eb752ac@gotplt.org> <1F7CF3D5-5AC3-4832-BE19-60F956A047F7@comcast.net> From: Siddhesh Poyarekar In-Reply-To: <1F7CF3D5-5AC3-4832-BE19-60F956A047F7@comcast.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3027.4 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,RCVD_IN_MSPIKE_H2,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 13:05, Paul Koning wrote: > > >> On Apr 13, 2023, at 1:00 PM, Siddhesh Poyarekar wrote: >> >> On 2023-04-13 12:49, Paul Koning wrote: >>> If someone sends me an executable file, and I execute it and suffer a virus, shame on me. If someone sends me a C source file and I compile and link that BUT DO NOT EXECUTE the resulting executable, and I suffer a virus, shame on the tool. >> >> If someone sends me a C source file and I compile and link it without inspecting it first, then definitely shame on me again. Compilers and linkers assume *trusted* input. > > That's news to me. > > It is true that not all text is valid C, and some text has "undefined" behavior. But "undefined" is a property of the resulting executable program, NOT of the act of compiling it. I have never before seen anyone suggest that submitting a bad program to a compiler could reasonably be expected to result in that compiler attacking the security of your system, or that if it did so it wouldn't be a security bug in that compiler. I haven't seen anyone suggest (and have seen many balk at) the idea of crashes/buffer overruns in compilers being considered security issues. Only lately (i.e. the last few years) has there been a spate of fuzzed reports that security researchers file CVEs for to increase their "kill" count. When we have the energy to do so, we dispute them and have them rejected, but many just go through, wasting days and weeks of time across the industry to respin builds and release updates. The only accepted security implication for compilers is when it takes in valid code and spews out a program that invoke undefined behaviour. >>> I don't expect the act of compiling or linking or objdumping to compromise my system's security, any more than I expect the act of editing a text file to do so. The key point is expectation. I'm reminded of a legal rule seen, for example, in "expectation of privacy": I should assume I can be seen when walking around town, but it is valid for me to assume I'm not seen when at home in my bathroom. Similarly, I should assume my system can get attacked when I execute a program, but it is reasonable for me to assume no attack is possible when I run gcc or objdump (or hexdump or cat). >> >> It's valid for you to assume that you're not seen when you're at home in your bathroom. However, if you take a random device someone gives you with you in your bathroom without actually checking what it does... >> >> Anyway like I said to Richard, it's all well and good to say that binutils *should* be able to handle untrusted inputs. The reality is that it is not in a position to make that claim and the only reasonable security position the project can take is to strongly recommend either validating inputs (to make them trusted) or running the tools in a sandbox. > > So what you're saying is that, at least in your view, the quality of binutils is so low that it is unlikely to meet the reasonable expectation I voiced. And furthermore, that it is in such bad shape that it's unreasonable to consider fixing it so it does meet those reasonable expectations. > > I rather doubt either assumption is true. But if it is, we should say so (or, arguably, discontinue the project). This is not the first time we've had this conversation[1] and there is a lot more nuance to this than "so you think binutils sux and should die". There are practical issues and design concerns that cannot be immediately addressed. Instead of giving the false impression of security, it makes more sense to make clear what the state of the project is and how users could safely consume it. Sid [1] https://inbox.sourceware.org/binutils/6f99c92f-1986-b8f0-0854-868598421dda@gotplt.org/t/