Re: Threat model for GNU Binutils

Petr Tesařík via Gdb
2023-04-14T16:45:46Z

On Fri, 14 Apr 2023 16:31:58 +0100
Richard Earnshaw <Richard.Earnshaw@foss.arm.com> wrote:

> On 14/04/2023 16:25, Petr Tesařík wrote:
> > On Fri, 14 Apr 2023 15:41:38 +0100
> > Richard Earnshaw via Gdb <gdb@sourceware.org> 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