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

[Richard Earnshaw <Richard.Earnshaw@foss.arm.com>]

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