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

Richard Earnshaw via Gdb
2023-04-14T09:52:55Z

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.