RFC: Adding a SECURITY.md document to the Binutils

[Siddhesh Poyarekar]

On 2023-04-14 05:52, Richard Earnshaw wrote:
>> 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?

You're the one who's saying that you don't trust binary objects obtained 
from signed packages even after verifying the signatures, not me :)

The term "untrusted" has a fairly clear meaning in this context; it is 
one that is obtained from an unfamiliar source that is cryptographically 
signed (that you can verify) as being valid.

Binaries on your system and/or those that your distribution provides are 
deemed trusted because you verify keys at various stages to reinforce 
your trust in the contents.

Binaries that people send for bug reports are *not* trusted unless the 
medium they used to send the binaries (e.g. private bug reporting tool 
where only verified users get to post) is trusted or the user is trusted 
(through a verified/signed email).

>>>>> 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.

They key is in what a project can feasibly guarantee and IMO the 
binutils project is not in a position to guarantee this level of 
security.  By putting this into SECURITY.md, we'll be signing ourselves 
(and downstream maintainers) up for much more than they can handle.

If the goal for being able to safely analyze untrusted binaries without 
sandboxing is desirable then the project needs to invest resources to 
making it happen, not make a promise first and then look for those 
resources.

Sid