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

On 2023-04-13 13:37, Paul Koning wrote:
>> I haven't seen anyone suggest (and have seen many balk at) the idea of crashes/buffer overruns in compilers being considered security issues.
> 
> Not all buffer overruns cause security issues.  Those that crash the program with the buffer overrun are not security issues (unless you're considering the category of Denial of Service attacks).  But a buffer overrun that enables the execution of arbitrary code IS a security issue.
> 
> Who do you know to "balk at" that principle?

I've discussed the idea of compiler bugs in general being considered 
security issues, not specifically about arbitrary code execution through 
a buffer overflow because of untrusted/crafted inputs.  I do in fact 
intend to write up a SECURITY.md for gcc, so perhaps it will become an 
opportunity to formalize this.

For binutils we need more people to pitch in to decide a direction since 
we don't have agreement yet.

> This is no different from how one analyzes buffer overruns in networking applications.  If the consequence of the error is nothing worse than an abort of that application, it's DoS and would typically not be considered serious.  If it allows code to be inserted and executed in the context of the application, then that is serious and is a security defect.  The same goes for any other application whose specification says that it processes -- but does not execute -- its inputs.

The seriousness of the DoS depends on the triviality of an attack. 
There can, for example, be Important DoS if it's trivial to invoke and 
is widely possible in default configurations.

Also, arbitrary code execution does not require code to be inserted; 
it's common to use ROPs/JOPs in existing code to achieve that.  This is 
also why memory safety bugs that don't always immediately result in a 
crash can be assumed in the worst case to result in arbitrary code 
execution.  Now whether that arbitrary code execution is security 
relevant depends on the context in which the bug can be exploited:

1. It could be through local access, in which case it is not security 
relevant because the user could run arbitrary code anyway

2. Untrusted local input (such as files downloaded off the internet), in 
which case it is security relevant if the application is hardened and 
designed to work on untrusted input

3. Remote input, in which case inputs are assumed to be untrusted and 
hence always security relevant

Binutils falls in 1. (for as, ld, etc.) and 2. (for readelf, objdump, 
etc.) and for case 2, it's upon us to decide whether we consider the 
tools hardened to work on untrusted inputs.  I don't think they are, 
which is why they need to be sandboxed to eliminate the security aspect 
of any bugs in them.

Sid