[PATCH] [RFCv2] Document Security process for binutils

[PATCH] [RFCv2] Document Security process for binutils

[Siddhesh Poyarekar]

[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

Re: [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.

Re: [PATCH] [RFCv2] Document Security process for binutils

[Siddhesh Poyarekar]

On 1/12/21 1:55 AM, Fangrui Song wrote:
> 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.

Unfortunately binutils does not have a wiki, so the choice was either 
the documentation or the web page that is duplicated between fsf.org and 
sourceware.org.  I chose documentation because that's where detailed 
information on reporting bugs currently lives.

Siddhesh

[PING][PATCH] [RFCv2] Document Security process for binutils

[Siddhesh Poyarekar]

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
> 

Re: [PING][PATCH] [RFCv2] Document Security process for binutils

[Alan Modra]

If you are serious about security then "don't run any of binutils as
root" is sufficient advice.  I don't think any of this documentation
in info files is necessary for binutils, and I'd rather not see more
people fuzzing binutils.

As someone who has spent rather a lot of time over the past year
responding to asan, ubsan, and fuzzed object file bug reports, I can
tell you that the great majority of those reports do not fix real
bugs.  By "real bugs", I mean bugs that might conceivably be triggered
by real object files created by compilers or assemblers.

Yes, we do have libbfd and libopcodes that are used by more than just
binutils and gdb, but the number of projects is small.

-- 
Alan Modra
Australia Development Lab, IBM

Re: [PING][PATCH] [RFCv2] Document Security process for binutils

[Siddhesh Poyarekar]

On 1/19/21 1:57 PM, Alan Modra wrote:
> If you are serious about security then "don't run any of binutils as
> root" is sufficient advice.  I don't think any of this documentation
> in info files is necessary for binutils, and I'd rather not see more
> people fuzzing binutils.
> 
> As someone who has spent rather a lot of time over the past year
> responding to asan, ubsan, and fuzzed object file bug reports, I can
> tell you that the great majority of those reports do not fix real
> bugs.  By "real bugs", I mean bugs that might conceivably be triggered
> by real object files created by compilers or assemblers.

What you said basically implies that running binutils tools in anything 
other than a fully trusted environments is unsupported, which eliminates 
all usage of binutils tools where they may be invoked remotely.

Also, running as root is not the only vector.  For example, one could in 
theory achieve remote code execution if binutils is invoked on untrusted 
binaries remotely.  It could either be directly through a service or by 
chaining with another bug that causes generation or storage of invalid 
binaries.

> Yes, we do have libbfd and libopcodes that are used by more than just
> binutils and gdb, but the number of projects is small.

Unfortunately that number is not zero and it is conceivable that the 
libraries may be used in an untrusted context.

The effect of such documentation is to clearly define usage patterns 
that will be accepted as CVE-worthy and as a result, limit them 
considerably.  In that sense, we're on the same team!

Perhaps explicitly stating that "Bugs in binutils that need tools to be 
run as root to be locally exploitable will be treated as regular bugs 
and not as security flaws" is a worthy addition?  Are there any other 
constraints for considering bugs as security issues that you can think 
of?  We could keep adding those as we go along.

Thanks,
Siddhesh

Re: [PING][PATCH] [RFCv2] Document Security process for binutils

[Mike Frysinger]

On 19 Jan 2021 14:29, Siddhesh Poyarekar wrote:
> On 1/19/21 1:57 PM, Alan Modra wrote:
> > If you are serious about security then "don't run any of binutils as
> > root" is sufficient advice.  I don't think any of this documentation
> > in info files is necessary for binutils, and I'd rather not see more
> > people fuzzing binutils.
> > 
> > As someone who has spent rather a lot of time over the past year
> > responding to asan, ubsan, and fuzzed object file bug reports, I can
> > tell you that the great majority of those reports do not fix real
> > bugs.  By "real bugs", I mean bugs that might conceivably be triggered
> > by real object files created by compilers or assemblers.
> 
> What you said basically implies that running binutils tools in anything 
> other than a fully trusted environments is unsupported, which eliminates 
> all usage of binutils tools where they may be invoked remotely.
> 
> Also, running as root is not the only vector.  For example, one could in 
> theory achieve remote code execution if binutils is invoked on untrusted 
> binaries remotely.  It could either be directly through a service or by 
> chaining with another bug that causes generation or storage of invalid 
> binaries.
> 
> > Yes, we do have libbfd and libopcodes that are used by more than just
> > binutils and gdb, but the number of projects is small.
> 
> Unfortunately that number is not zero and it is conceivable that the 
> libraries may be used in an untrusted context.
> 
> The effect of such documentation is to clearly define usage patterns 
> that will be accepted as CVE-worthy and as a result, limit them 
> considerably.  In that sense, we're on the same team!
> 
> Perhaps explicitly stating that "Bugs in binutils that need tools to be 
> run as root to be locally exploitable will be treated as regular bugs 
> and not as security flaws" is a worthy addition?  Are there any other 
> constraints for considering bugs as security issues that you can think 
> of?  We could keep adding those as we go along.

i'm with Alan here with the current state of the world: it is not safe to
run binutils (or gcc fwiw) on untrusted inputs unless the overall execution
environment has been isolated/secured in someway.  i understand that some
people will find this surprising, but that is the reality of the codebase
today.  i've been telling people this in Gentoo for decades.  i don't see
the situation changing until someone steps up to comprehensively tackle it.

i agree that we should have a document clearly defining the security
posture of the project as people will go looking for it.  but trying to do
embargoes or new branch releases for every bug with exploit possibilities
will be useless drain on an already limited developer pool.  bugs should be
treated as bugs which means using bugzilla to report them.

if you think there should be a better answer here, then realistically you'll
have to get a company/etc... to provide dedicated resources in this space.
imo, we're talking something like isolating all bfd operations into a secure
context (e.g. dropping caps, using seccomp mode1 if possible, etc...).
-mike

Re: [PING][PATCH] [RFCv2] Document Security process for binutils

[Siddhesh Poyarekar]

On 1/26/21 8:16 AM, Mike Frysinger wrote:
> i'm with Alan here with the current state of the world: it is not safe to
> run binutils (or gcc fwiw) on untrusted inputs unless the overall execution
> environment has been isolated/secured in someway.  i understand that some
> people will find this surprising, but that is the reality of the codebase
> today.  i've been telling people this in Gentoo for decades.  i don't see
> the situation changing until someone steps up to comprehensively tackle it.

I don't disagree, but that seems more like an assessment of the 
robustness in handling untrusted input than a design choice.  Also, 
there's a distinction to be made between the tools and the libraries 
shipped in binutils in terms of how we can dictate use cases.

Either way, documenting this as an explicit project stance may help set 
expectations of users.

> i agree that we should have a document clearly defining the security
> posture of the project as people will go looking for it.  but trying to do
> embargoes or new branch releases for every bug with exploit possibilities
> will be useless drain on an already limited developer pool.  bugs should be
> treated as bugs which means using bugzilla to report them.

 From glibc experience, embargoes are probably the only additional 
overhead.  AFAICT, we already backport security fixes to older branches 
based on the severity of the fix.  If anything, the documentation would 
help *limit* what gets called a security issue.  For example, this[1] 
would have got promptly thrown out if there was a security process; I'm 
sure there are others that sneaked in earlier that resulted in pointless 
churn under the pretext of it being a security issue.

> if you think there should be a better answer here, then realistically you'll
> have to get a company/etc... to provide dedicated resources in this space.

FWIW, my focus in Red Hat is to look at toolchain security, so I'm 
pretty close to being the dedicated resource you're imagining.  It is 
also why I'm trying to help formulate a formal security process.  I am 
also signing up to follow that process :)

> imo, we're talking something like isolating all bfd operations into a secure
> context (e.g. dropping caps, using seccomp mode1 if possible, etc...).

I agree, isolation would be an interesting feature, but it still remains 
a mitigation technique.  I am also going to look (maybe later this year) 
at past fuzzing results to see if there's potential cleanup that we can 
do across the library to make it safer.

Siddhesh

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=25840

Re: [PING][PATCH] [RFCv2] Document Security process for binutils

[Mike Frysinger]

On 27 Jan 2021 09:28, Siddhesh Poyarekar wrote:

i've responded inline to points below, but i'll preface things to try and head
off misunderstandings as it sounds like i'm all doom & gloom.  i'm not happy
about the current state of the project wrt security, but i'm being practical
given the engineering resources we have.  if we had programmers dedicated to
the task of coming up with fundamental solutions to how these libraries work
or are implemented and make it hard for incorrect code to be merged in the
first place, then i'd be a lot more supportive of a formalized & dedicated
security process (including private channels, embargoes, dedicated releases,
and all that).  remember that we accept ports & contributions from anyone,
not just corporations, and many of them don't have the time or resources or
incentives or expertise to assess the security or robustness of their code.
requiring them to go through an independent security audit (or equiv) before
merging is untenable.

so given the current state, i'd only be supportive of treating all bugs as
bugs with no security qualifiers, make those expectations clear to devs and
users in the manual/homepage, and generally not try and rush releases just
to fix a "security" issue.

(not that i'm a head/global binutils maintainer and have any sort of
authority in this space to make any project-wide decision)

> On 1/26/21 8:16 AM, Mike Frysinger wrote:
> > i'm with Alan here with the current state of the world: it is not safe to
> > run binutils (or gcc fwiw) on untrusted inputs unless the overall execution
> > environment has been isolated/secured in someway.  i understand that some
> > people will find this surprising, but that is the reality of the codebase
> > today.  i've been telling people this in Gentoo for decades.  i don't see
> > the situation changing until someone steps up to comprehensively tackle it.
> 
> I don't disagree, but that seems more like an assessment of the 
> robustness in handling untrusted input than a design choice.

at this point, as long as resources aren't dedicated to changing the
situation, it's a distinction without a difference.

> there's a distinction to be made between the tools and the libraries 
> shipped in binutils in terms of how we can dictate use cases.

i understand what you mean, but i disagree.  if {tool|library} can be fed
untrusted input that turns into a crash, or into arbitrary code exec, it
would be reported the same way.  from the binutils project pov, the same
amount of effort will need to be expended.  maybe the CVE score would be
different, but it would still prompt a CVE and expectation of a fixed
release.  CVE's are like -Werror: people consider any output a failure.

> > i agree that we should have a document clearly defining the security
> > posture of the project as people will go looking for it.  but trying to do
> > embargoes or new branch releases for every bug with exploit possibilities
> > will be useless drain on an already limited developer pool.  bugs should be
> > treated as bugs which means using bugzilla to report them.
> 
>  From glibc experience, embargoes are probably the only additional 
> overhead.  AFAICT, we already backport security fixes to older branches 
> based on the severity of the fix.

there are no "older branches" in this world.  there is the main development
branch, and there is an active release branch.  the release branch has bug
fixes cherry-picked to it as people request them, and new versions trickle
out as changes accumulate, and someone feels like kicking it out.

> If anything, the documentation would 
> help *limit* what gets called a security issue.  For example, this[1] 
> would have got promptly thrown out if there was a security process; I'm 

we can already throw them all out: if you use binutils in contexts that are
insufficiently secure by themselves, it's a failing in the environment.

> sure there are others that sneaked in earlier that resulted in pointless 
> churn under the pretext of it being a security issue.

i don't think this is accurate.  do you have examples ?  people reporting
bugs and then having them be fixed, regardless of security implication, is
not churn imo.  it's not like we'd ever argue "that input was specially
crafted by you, therefore we don't care that it causes a crash".  files
could just as easily be corrupted by your computer (e.g. filesystem).

if you look at the release history, it seems like the release schedule has
been unpeturbed by any reported issues.
https://sourceware.org/pub/binutils/releases/?C=M;O=D

CVE-2014-8485 (the one about `strings`) is about the only one i can remember
where i'd make a concession given the current situation.  and one concession
per decade or two doesn't seem like the current approach isn't "working".

> > if you think there should be a better answer here, then realistically you'll
> > have to get a company/etc... to provide dedicated resources in this space.
> 
> FWIW, my focus in Red Hat is to look at toolchain security, so I'm 
> pretty close to being the dedicated resource you're imagining.  It is 
> also why I'm trying to help formulate a formal security process.  I am 
> also signing up to follow that process :)

that is insufficient.  creating the appearance of security when the project
and codebase is not backing it up is worse.  we're polishing a turd and then
selling it as kobe beef knowing full well it's a turd.

having dedicated resources such as yourself to manage logistics is important
and engineers can't replace that.  but conversely, the engineering resources
need to be in place too.  if either is missing, then it all falls down.

> > imo, we're talking something like isolating all bfd operations into a secure
> > context (e.g. dropping caps, using seccomp mode1 if possible, etc...).
> 
> I agree, isolation would be an interesting feature, but it still remains 
> a mitigation technique.

that's like saying not running everything as root is a mitigation technique.
i mean, i guess, but it's a fundamental defense that completely cuts off any
other problems.  if you're in seccomp mode1 and get arbitrary code exec, then
no one cares.  all you've got is a DoS at best.  and if we, as a project, say
that a DoS is just another bug and not one worthy of security handling, then
that simplifies quite a lot.

as long as the libs are written in C, mitigation techniques are the only real
defense option.  i assume switching to a memory safe language (e.g. Rust) is
off the table.

or something like moving all arch-specific code to be declarative (cgen?),
and then we only have a single common core to focus on securing.

> I am also going to look (maybe later this year) 
> at past fuzzing results to see if there's potential cleanup that we can 
> do across the library to make it safer.

imo this approach is woefully insufficient to accept a stronger security
position.  if it were all low hanging fruit & easy fixes, i'm pretty sure
we would have already gotten there.

i think Alan already said he's been responding to sanitizers & fuzzers for
over a year without being terribly impressed.  i don't think that's an
indictment of either tool (i love them both & actively use them), but it
is a testament that they aren't the solution to our troubles.
-mike

Re: [PING][PATCH] [RFCv2] Document Security process for binutils

[Siddhesh Poyarekar]

On 1/27/21 11:06 AM, Mike Frysinger wrote:
> i've responded inline to points below, but i'll preface things to try and head
> off misunderstandings as it sounds like i'm all doom & gloom.  i'm not happy
> about the current state of the project wrt security, but i'm being practical
> given the engineering resources we have.  if we had programmers dedicated to
> the task of coming up with fundamental solutions to how these libraries work
> or are implemented and make it hard for incorrect code to be merged in the
> first place, then i'd be a lot more supportive of a formalized & dedicated
> security process (including private channels, embargoes, dedicated releases,
> and all that).  remember that we accept ports & contributions from anyone,
> not just corporations, and many of them don't have the time or resources or
> incentives or expertise to assess the security or robustness of their code.
> requiring them to go through an independent security audit (or equiv) before
> merging is untenable.

Got it.  I suppose my view is limited to Linux distribution maintainers 
where we already have much of this in place and we already have to 
acknowledge, evaluate and backport security issues in binutils.

>> On 1/26/21 8:16 AM, Mike Frysinger wrote:
>>> i'm with Alan here with the current state of the world: it is not safe to
>>> run binutils (or gcc fwiw) on untrusted inputs unless the overall execution
>>> environment has been isolated/secured in someway.  i understand that some
>>> people will find this surprising, but that is the reality of the codebase
>>> today.  i've been telling people this in Gentoo for decades.  i don't see
>>> the situation changing until someone steps up to comprehensively tackle it.
>>
>> I don't disagree, but that seems more like an assessment of the
>> robustness in handling untrusted input than a design choice.
> 
> at this point, as long as resources aren't dedicated to changing the
> situation, it's a distinction without a difference.
> 
>> there's a distinction to be made between the tools and the libraries
>> shipped in binutils in terms of how we can dictate use cases.
> 
> i understand what you mean, but i disagree.  if {tool|library} can be fed
> untrusted input that turns into a crash, or into arbitrary code exec, it
> would be reported the same way.  from the binutils project pov, the same
> amount of effort will need to be expended.  maybe the CVE score would be
> different, but it would still prompt a CVE and expectation of a fixed
> release.  CVE's are like -Werror: people consider any output a failure.
> 
>>> i agree that we should have a document clearly defining the security
>>> posture of the project as people will go looking for it.  but trying to do
>>> embargoes or new branch releases for every bug with exploit possibilities
>>> will be useless drain on an already limited developer pool.  bugs should be
>>> treated as bugs which means using bugzilla to report them.
>>
>>   From glibc experience, embargoes are probably the only additional
>> overhead.  AFAICT, we already backport security fixes to older branches
>> based on the severity of the fix.
> 
> there are no "older branches" in this world.  there is the main development
> branch, and there is an active release branch.  the release branch has bug
> fixes cherry-picked to it as people request them, and new versions trickle
> out as changes accumulate, and someone feels like kicking it out.
> 
>> If anything, the documentation would
>> help *limit* what gets called a security issue.  For example, this[1]
>> would have got promptly thrown out if there was a security process; I'm
> 
> we can already throw them all out: if you use binutils in contexts that are
> insufficiently secure by themselves, it's a failing in the environment.
> 
>> sure there are others that sneaked in earlier that resulted in pointless
>> churn under the pretext of it being a security issue.
> 
> i don't think this is accurate.  do you have examples ?  people reporting
> bugs and then having them be fixed, regardless of security implication, is
> not churn imo.  it's not like we'd ever argue "that input was specially
> crafted by you, therefore we don't care that it causes a crash".  files
> could just as easily be corrupted by your computer (e.g. filesystem).
> 
> if you look at the release history, it seems like the release schedule has
> been unpeturbed by any reported issues.
> https://sourceware.org/pub/binutils/releases/?C=M;O=D

The churn is from a distribution perspective where backport decisions 
may be influenced by the potential security impact of a bug.  Having the 
upstream project clearly call out a bug as not being CVE-worthy based on 
defined criteria would make it easier for downstream to prioritize.  I 
suppose it could be argued that it's a downstream-only concern.

> that is insufficient.  creating the appearance of security when the project
> and codebase is not backing it up is worse.  we're polishing a turd and then
> selling it as kobe beef knowing full well it's a turd.
> 
> having dedicated resources such as yourself to manage logistics is important
> and engineers can't replace that.  but conversely, the engineering resources
> need to be in place too.  if either is missing, then it all falls down.

Ahh no, the logistics management under the current proposal could be 
handled by the distribution security teams since they're already doing it.

> that's like saying not running everything as root is a mitigation technique.
> i mean, i guess, but it's a fundamental defense that completely cuts off any
> other problems.  if you're in seccomp mode1 and get arbitrary code exec, then
> no one cares.  all you've got is a DoS at best.  and if we, as a project, say
> that a DoS is just another bug and not one worthy of security handling, then
> that simplifies quite a lot.

I totally agree, maybe the way I wrote it understated my complete 
agreement :)

> as long as the libs are written in C, mitigation techniques are the only real
> defense option.  i assume switching to a memory safe language (e.g. Rust) is
> off the table.
> 
> or something like moving all arch-specific code to be declarative (cgen?),
> and then we only have a single common core to focus on securing.

+1

>> I am also going to look (maybe later this year)
>> at past fuzzing results to see if there's potential cleanup that we can
>> do across the library to make it safer.
> 
> imo this approach is woefully insufficient to accept a stronger security
> position.  if it were all low hanging fruit & easy fixes, i'm pretty sure
> we would have already gotten there.
> 
> i think Alan already said he's been responding to sanitizers & fuzzers for
> over a year without being terribly impressed.  i don't think that's an
> indictment of either tool (i love them both & actively use them), but it
> is a testament that they aren't the solution to our troubles.

No no, I don't want to run fuzzers all over again.  I meant to look at 
patterns across previous reports to see if there are systemic issues I 
could help solve in libbfd to make it safer.  Things like declarative 
architecture-specific code, safer file handling, consolidating common 
logic across architectures, etc.

Siddhesh