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

Richard Earnshaw via Gdb
2023-04-13T14:51:42Z

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

No, whilst elf can be executed, objdump should never be doing that: it's
a tool for examining a file, not running it. You have to have a tool
that can safely examine the contents of an elf file or you can never
verify it for issues - opening it up in emacs to examine the contents is
not the way to do that :)

But all that is beside the point. The original case I gave was a
/corrupt/ elf file that caused a buffer overrun in the objdump binary.

R.