Threat model for GNU Binutils

[Richard Earnshaw]

OK, I think it's time to take a step back.

If we are to have a security policy, I think we first need a threat 
model.  Without it, we can't really argue about what we're trying to 
protect against.

So the attached is my initial stab at trying to write down a threat 
model.  Some of this is subjective, but I'm trying to be reasonably 
realistic.  Most of these threats are really quite low in comparison to 
other tools and services that run on your computer.

In practice, you then take the model and the impact/likelihood matrix 
and decide what level of actions are needed for each combination - 
whether it be from pre-emptive auditing through fixing bugs if found 
down to do nothing.   But that's the step after we have the model agreed.

If you can think of threats I've missed (quite likely, I haven't thought 
about this for long enough), then please suggest additions.

R.
-------------- next part --------------
Threat model for GNU Binutils
=============================

The following potential security threats have been identified in GNU
Binutils.  Note that this does not mean that such a vulnerability is
known to exist.

Threats arising from execution of the GNU Binutils programs
-----------------------------------------------------------

1) Privilege escalation.

  Nature:
  A bug in the tools allows the user to gain privileges that they did not
  already have.

  Likelihood: Low - tools do not run with elevated privileges, so this
  would most likely involve a bug in the kernel.

  Impact: Critical

  Mitigation: None

2) Denial of service

  Nature:
  A bug in the tools leads to resources in the system becoming
  unavailable on a temporary or permanent basis

  Likelihood: Low

  Impact: Low - tools are normally run under local user control and
  not as daemons.

  Mitigation: sandboxing if access to the tools from a third party is
  needed (eg a web service).

3) Data corruption leads to uncontrolled program execution.

  Nature:
  A bug such as unconstrained buffer overflow could lead to a ROP or JOP
  style attack if not fully contained.  Once in control an attacker
  might be able to access any file that the user running the program has
  access to.

  Likelihood: Moderate

  Impact: High

  Mitigation: sandboxing can help if an attacker has direct control
  over inputs supplied to the tools or in cases where the inputs are
  particularly untrustworthy, but is not practical during normal
  usage.

Threats arising from execution of output produced by GNU Binutils programs
--------------------------------------------------------------------------

Note for this category we explicitly exclude threats that exist in the
input files supplied to the tools and only consider threats introduced
by the tools themselves.

1) Incorrect generation of machine instructions leads to unintended
program behavior.

  Nature:
  Many architectures have 'don't care' bits in the machine instructions.
  Generally the architecture will specify the value that such bits have,
  leaving room for future expansion of the instruction set.  If tools do
  not correctly set these bits then a program may execute correctly on
  some machines, but fail on others.

  Likelihood: Low

  Impact: Moderate - this is unlikely to lead to an exploit, but might lead
  to DoS in some cases.

  Mitigation: cross testing generated output against third-party toolchain
  implementations.

2) Code directly generated by the tools contains a vulnerability

  Nature:
  The vast majority of code output from the tools comes from the input
  files supplied, but a small amount of 'glue' code might be needed in
  some cases, for example to enable jumping to another function in
  another part of the address space.  Linkers are also sometimes asked
  to inject mitigations for known CPU errata when this cannot be done
  during the compilation phase.

  Likelihood: low

  Impact: mostly low - the amount of code generated is very small and
  unlikely to involve buffers that contain risky data, so the chances of
  this directly leading to a vulnerability is low.

  Mitigation: monitor for processor vendor vulnerabilities and adjust tool
  code generation if needed.