Threat model for GNU Binutils

Richard Earnshaw via Gdb
2023-04-14T13:13:21Z

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

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.

[-- Attachment #2: binutils-threats.txt --]
[-- Type: text/plain, Size: 3262 bytes --]

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.