Re: Threat model for GNU Binutils

On Fri, 14 Apr 2023 16:31:58 +0100
Richard Earnshaw <[email protected]> wrote:

> On 14/04/2023 16:25, Petr Tesařík wrote:
> > 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  
> 
> This probably comes under the 2) of generated output, but it could be 
> more explicit.  Layout bugs is also something Sid alluded to with his 
> comments about alignment.

Ah. Since you wrote "code", I had the impression you considered only
machine code. I wanted to make it clear that *anything* in the output
can be potentially security-relevant.

Petr T