From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from buffalo.birch.relay.mailchannels.net (buffalo.birch.relay.mailchannels.net [23.83.209.24]) by sourceware.org (Postfix) with ESMTPS id 76A9D38708DC for ; Mon, 18 Jan 2021 19:09:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 76A9D38708DC Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=siddhesh@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 D97A2182AD4; Mon, 18 Jan 2021 19:09:29 +0000 (UTC) Received: from pdx1-sub0-mail-a11.g.dreamhost.com (100-105-161-30.trex.outbound.svc.cluster.local [100.105.161.30]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 76A41182E86; Mon, 18 Jan 2021 19:09:28 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from pdx1-sub0-mail-a11.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/6.0.1); Mon, 18 Jan 2021 19:09:29 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Lettuce-Lonely: 0d937e8c3575d091_1610996969749_3607837273 X-MC-Loop-Signature: 1610996969749:3106591245 X-MC-Ingress-Time: 1610996969749 Received: from pdx1-sub0-mail-a11.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a11.g.dreamhost.com (Postfix) with ESMTP id 352BC7F35C; Mon, 18 Jan 2021 11:09:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gotplt.org; h=subject:to :cc:references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; s=gotplt.org; bh=zborkt 86T4eEc2Jw8YtYNFB2IsQ=; b=BR1Jp2PC/ykm6vW1y65pvKwAEUFAVsSj8U38P+ zFPsE6iwbusf6JX6g+ihOKmGTYqr+roWcA12C/RsTfMTGmfHES0U6VnI5EmWZgiL Ocx0My2gO874A2xnNQ3QCCa0wcNepPEloJd+jfe0OGB5vlM4ZGBKb0io6z1btXmE ywx54= Received: from [192.168.86.152] (unknown [103.199.172.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a11.g.dreamhost.com (Postfix) with ESMTPSA id 09DD87FF17; Mon, 18 Jan 2021 11:09:25 -0800 (PST) Subject: [PING][PATCH] [RFCv2] Document Security process for binutils To: binutils@sourceware.org Cc: fweimer@redhat.com, nickc@redhat.com References: <20210108095941.417093-1-siddhesh@gotplt.org> X-DH-BACKEND: pdx1-sub0-mail-a11 From: Siddhesh Poyarekar Message-ID: <53ac9309-bb52-3291-b307-33076b9d0468@gotplt.org> Date: Tue, 19 Jan 2021 00:39:14 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20210108095941.417093-1-siddhesh@gotplt.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3036.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_ABUSEAT, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2021 19:09:35 -0000 On 1/8/21 3:29 PM, Siddhesh Poyarekar wrote: > [Oops, forgot to add links, sorry] > > Hi, > > Fuzzing of binutils has in the recent past exposed many bugs in > binutils utilities and that has over time improved the reliability of > these utilities. Quite a few of those bugs were also found to have > security implications and hence the activity also improved the state > of security in binutils. > > However there have been a number of cases where it hasn't been clear > if a bug has security implications and due to lack of a clear security > policy or process, spurious CVE assignments were made. One such > example is this bug[1] which is a crash that got incorrectly described > as a DoS and got CVE-2020-16598[2], an error which was thankfully > corrected later on. > > The draft below is a starting point to specify the properties of bugs > in binutils that make it a security vulnerability. It also gives > guidelines for who to contact for private security issues with a > placeholder email address. The content is based on the glibc security > process[3]. The idea is to add a link to the binutils web pages[4][5] > to point to the binutils Security Bugs manual node. > > Outstanding questions: > > - Are the conditions for a bug to be a security vulnerability too > strict or too loose? > > - Is this the right place for this text? > > - Who should be the contact for private security bugs? As with glibc, > I could reach out to distribution security teams to see if they'd be > willing to be coordinators for binutils bugs too. Alternatively, it > could be an email alias that auto-forwards to named people in the > community. Otherwise, it could be a list of named email addresses. > > - Would gdb like to get on board this? I suppose this is a question > to ask (and propose the patch for) on the gdb mailing list, but in > the event any gdb folks are listening in here, I'd love to get > initial impressions. > > Siddhesh > > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=25840 > [2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16598 > [3] https://sourceware.org/glibc/wiki/Security%20Process > [4] https://sourceware.org/binutils/ > [5] https://www.gnu.org/software/binutils/ > > --- > binutils/doc/binutils.texi | 70 ++++++++++++++++++++++++++++++++++++++ > gas/doc/as.texi | 51 +++++++++++++++++++++++++++ > ld/ld.texi | 51 +++++++++++++++++++++++++++ > 3 files changed, 172 insertions(+) > > diff --git a/binutils/doc/binutils.texi b/binutils/doc/binutils.texi > index 671694f8111..691244c8d0c 100644 > --- a/binutils/doc/binutils.texi > +++ b/binutils/doc/binutils.texi > @@ -5353,6 +5353,7 @@ information that enables us to fix the bug. > @menu > * Bug Criteria:: Have you found a bug? > * Bug Reporting:: How to report bugs > +* Security Bugs:: Considerations on reporting security issues. > @end menu > > @node Bug Criteria > @@ -5539,6 +5540,75 @@ Such guesses are usually wrong. Even we cannot guess right about such > things without first using the debugger to find the facts. > @end itemize > > +@node Security Bugs > +@section What is a security bug? > +@cindex security bug > +@cindex security > + > +It is expected that programs and libraries provided by @file{binutils} may get > +used in contexts that may result in bugs in those utilities having security > +implications. However, it is not always clear if the security implication is > +due to @file{binutils} behaviour or the environment. One may use the following > +guideline to determine if a bug in @file{binutils} is considered as a security > +bug. When in doubt, the reporter may either reach out to the security contact > +or ask on @email{binutils@@sourceware.org}. > + > +@itemize @bullet > +@item > +A crash in any library (e.g. @file{libbfd.so}) provided by binutils may be > +treated as a security issue unless it is triggered by inputs that are > +documented as invalid in the @file{binutils} documentation. It is the > +responsibility of the caller to sanitize those inputs. > + > +@item > +A crash in a program (e.g. @file{readelf}, @file{objdump}, @file{strip}) > +provided by binutils is not a security issue if it does not result in > +escalation of privileges. Services invoking these programs are expected to > +handle failures in execution and avoid any potential Denial of Service. > + > +@item > +A bug in a library or program provided by binutils may be considered a security > +issue if it results in escalation of privileges. > +@end itemize > + > +@section Reporting Private Security Bugs > +@cindex private security bugs > + > +In general if a bug may be exploited over the network or may be used for > +privilege escalation (through existing applications, not synthetic test cases), > +it should be reported privately. If you are unsure about the criticality or > +sensitivity of a security issue you wish to report, you could report it > +privately too. > + > +To report a security issue privately, please contact > +@email{REPLACE_ME_WITH_AN_ACTUAL_NAME@@sourceware.org} with details of the bug. > + > +This email is monitored by the binutils security team and will take care of > +details such as vulnerability rating and CVE assignment. It is likely that the > +team will ask to file a public bug because the issue is sufficiently minor and > +does not warrant an embargo. An embargo is not a requirement for being credited > +with the discovery of a security vulnerability. > + > +@section Reporting Public Security Bugs > +@cindex reporting security bugs > +@cindex security reporting > + > +To share a public security report, create a bug as described in > +@ref{Bug Reporting} and set the @code{security} flag in the `Flags` > +section to @samp{?}. If the bug is confirmed to be a security issue, the > +following will be done: > + > +@itemize @bullet > +@item > +The @code{security} flag is set to @samp{+}. > +@item > +The CVE number assigned to the bug is added to the bug as an alias as well as > +appended to the end of the bug title. > +@end itemize > + > +If the bug is not considered a security issue, the @code{security} flag is set > +to @samp{-}. > + > @node GNU Free Documentation License > @appendix GNU Free Documentation License > > diff --git a/gas/doc/as.texi b/gas/doc/as.texi > index 983cec3cbf9..81516c78c7e 100644 > --- a/gas/doc/as.texi > +++ b/gas/doc/as.texi > @@ -8229,6 +8229,7 @@ information that enables us to fix the bug. > @menu > * Bug Criteria:: Have you found a bug? > * Bug Reporting:: How to report bugs > +* Security Bugs:: Considerations on reporting security issues. > @end menu > > @node Bug Criteria > @@ -8415,6 +8416,56 @@ Such guesses are usually wrong. Even we cannot guess right about such > things without first using the debugger to find the facts. > @end itemize > > +@node Security Bugs > +@section What is a security bug? > +@cindex security bug > +@cindex security > + > +In general, a bug in the GNU assembler may be considered a security issue only > +if the bug somehow results in escalation of privileges. Services invoking the > +GNU assembler are expected to handle failures in the program, including > +crashes, and thus ensure service continuity. > + > +If in doubt, you may either reach out to the distribution security teams or ask > +on @email{binutils@@sourceware.org}. > + > +@section Reporting Private Security Bugs > +@cindex private security bugs > + > +In general if a bug may be exploited over the network or may be used for > +privilege escalation (through existing applications, not synthetic test cases), > +it should be reported privately. If one is in doubt about the criticality of a > +security issue they wish to report, they could report it privately too. > + > +To report a security issue privately, please contact > +@email{REPLACE_ME_WITH_AN_ACTUAL_NAME@@sourceware.org} with details of the bug. > + > +This email is monitored by the binutils security team and will take care of > +details such as vulnerability rating and CVE assignment. It is likely that the > +team will ask to file a public bug because the issue is sufficiently minor and > +does not warrant an embargo. An embargo is not a requirement for being credited > +with the discovery of a security vulnerability. > + > +@section Reporting Public Security Bugs > +@cindex reporting security bugs > +@cindex security reporting > + > +To share a public security report, create a bug as described in > +@ref{Bug Reporting} and set the @code{security} flag in the `Flags` > +section to @samp{?}. If the bug is confirmed to be a security issue, the > +following will be done: > + > +@itemize @bullet > +@item > +The @code{security} flag is set to @samp{+}. > +@item > +The CVE number assigned to the bug is added to the bug as an alias as well as > +appended to the end of the bug title. > +@end itemize > + > +If the bug is not considered a security issue, the @code{security} flag is set > +to @samp{-}. > + > @node Acknowledgements > @chapter Acknowledgements > > diff --git a/ld/ld.texi b/ld/ld.texi > index 8e3c7da145e..29b0ee07c67 100644 > --- a/ld/ld.texi > +++ b/ld/ld.texi > @@ -8807,6 +8807,7 @@ information that enables us to fix the bug. > @menu > * Bug Criteria:: Have you found a bug? > * Bug Reporting:: How to report bugs > +* Security Bugs:: Considerations on reporting security issues. > @end menu > > @node Bug Criteria > @@ -9004,6 +9005,56 @@ Such guesses are usually wrong. Even we cannot guess right about such > things without first using the debugger to find the facts. > @end itemize > > +@node Security Bugs > +@section What is a security bug? > +@cindex security bug > +@cindex security > + > +In general, a bug in the GNU linker may be considered a security issue only if > +the bug somehow results in escalation of privileges. Services invoking > +@command{ld} are expected to handle failures in the program, including crashes, > +and thus ensure service continuity. > + > +If in doubt, you may either reach out to the distribution security teams or ask > +on @email{binutils@@sourceware.org}. > + > +@section Reporting Private Security Bugs > +@cindex private security bugs > + > +In general if a bug may be exploited over the network or may be used for > +privilege escalation (through existing applications, not synthetic test cases), > +it should be reported privately. If one is in doubt about the criticality of a > +security issue they wish to report, they could report it privately too. > + > +To report a security issue privately, please contact > +@email{REPLACE_ME_WITH_AN_ACTUAL_NAME@@sourceware.org} with details of the bug. > + > +This email is monitored by the binutils security team and will take care of > +details such as vulnerability rating and CVE assignment. It is likely that the > +team will ask to file a public bug because the issue is sufficiently minor and > +does not warrant an embargo. An embargo is not a requirement for being credited > +with the discovery of a security vulnerability. > + > +@section Reporting Public Security Bugs > +@cindex reporting security bugs > +@cindex security reporting > + > +To share a public security report, create a bug as described in > +@ref{Bug Reporting} and set the @code{security} flag in the `Flags` > +section to @samp{?}. If the bug is confirmed to be a security issue, the > +following will be done: > + > +@itemize @bullet > +@item > +The @code{security} flag is set to @samp{+}. > +@item > +The CVE number assigned to the bug is added to the bug as an alias as well as > +appended to the end of the bug title. > +@end itemize > + > +If the bug is not considered a security issue, the @code{security} flag is set > +to @samp{-}. > + > @node MRI > @appendix MRI Compatible Script Files > @cindex MRI compatibility >