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

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.