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

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