Re: RFC: Adding a SECURITY.md document to the Binutils

Richard Earnshaw via Gdb
2023-04-13T12:38:08Z

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