[PATCH] [RFC] Document Security process for binutils
Siddhesh Poyarekar
siddhesh@gotplt.org
Fri Jan 8 09:53:57 GMT 2021
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
---
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
More information about the Binutils
mailing list