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

Siddhesh Poyarekar
2023-04-13T13:57:03Z

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

You're mixing up scope. Given the flexibility of ELF, it is possible to
get any ELF interpreter to do pretty much anything[1], including sending
files to arbitrary places, deleting parts of the filesystem the
executing user has access to, etc. It is the responsibility of the
layer outside of objdump (i.e. the execution environment) to constrain this.

To secure objdump and other tools from such compromise, what you'd
actually need is, e.g. a --isolate flag that does an unshare()/chroot()
holding the open file descriptor and does a very constrained analysis of
untrusted binaries. That's one way we could control the execution
environment to make sure none of it leaks.

Sid

[1] https://www.usenix.org/system/files/conference/woot13/woot13-shapiro.pdf