Re: Threat model for GNU Binutils

On Fri, 14 Apr 2023 15:41:38 +0100
Richard Earnshaw via Gdb <[email protected]> wrote:

> On 14/04/2023 15:08, Siddhesh Poyarekar wrote:
> > On 2023-04-14 09:12, Richard Earnshaw wrote:  
>[...]
> >> 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.  
> > 
> > Since you've split this one out from machine instructions, there's a 
> > third category too; where binutils tools generate incorrect code for 
> > alignment of sections, sizes of sections, etc.  There's also a (rare) 
> > possibility of an infrequently used instruction having incorrect opcode 
> > mapping, resulting in a bug being masked when dumped with objdump or 
> > resulting code having undefined behaviour.
> >   

I must be dumb, but isn't the biggest risk is that GNU Binutils produce
an exploitable bug in the target binary?

Let me give a silly hypothetical example. If the linker places Global
Offset Table incorrectly, so that it overlaps stack, then I would
definitely consider it a security bug in GNU Binutils, because all
input object files were OK, but the result is not.

Just my two cents,
Petr T