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

[Richard Earnshaw <Richard.Earnshaw@foss.arm.com>]

On 13/04/2023 17:42, Siddhesh Poyarekar wrote:
> On 2023-04-13 11:05, Richard Earnshaw wrote:
>> On 13/04/2023 16:02, Siddhesh Poyarekar wrote:
>>> On 2023-04-13 10:50, Richard Earnshaw wrote:
>>>> 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 :)
>>>
>>> You can verify it for issues, in a sandbox.
>>
>> Maybe.  But not always, it might not crash the program, but still lead 
>> to issues once taken outside of the sandbox.
> 
> You don't analyze untrusted data outside of a sandbox.  Really, it's 
> security 101.

I think your definition of trusted and untrusted must vary from mine. 
And I think your expectations on users is somewhat unreasonable.

In my book any binary object obtained from the internet is /potentially/ 
untrusted.  That includes any object file that is downloaded from, say, 
a Red Hat server in an RPM package (even if it's been signed).  Are you 
seriously suggesting that every user should deal with every file as 
though it was completely untrustworthy?

> 
>>>> 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.
>>>
>>> ... and that's a robustness issue.  Any buffer overrun in any program 
>>> could in theory be exploited to send out files.
>>>
>>
>> So what's your point?  These /are/ vulnerabilities in the program and 
>> need to be considered security issues.
> 
> I already made my point; I agree that they are security issues but the 
> security mitigation mechanism is in the environment, not the program.  I 
> do not think it is in the interest of the binutils project to guarantee 
> safety in analysis of untrusted programs without requisite protections 
> of the environment.
> 
> Sid

Any buffer overflow where the data used to do the overflow comes from an 
object file is a potential breach, unless the program can detect this 
and make a controlled abort before any possible break-out can occur.

The key here is defence in depth.  It's not enough to say that 
everything must be done in a sandbox, even if that is advisable.

R.