[PATCH] [RFCv2] Document Security process for binutils

[Fangrui Song]

On Fri, Jan 8, 2021 at 1:59 AM Siddhesh Poyarekar <siddhesh@gotplt.org> 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
> --
> 2.29.2
>

As a user (and occasional contributor), having the information on a
wiki page (like
https://sourceware.org/glibc/wiki/Security%20Process#What_is_a_security_bug.3F)
is sufficient for me.