Re: Threat model for GNU Binutils

Richard Earnshaw via Gdb
2023-04-14T15:32:29Z

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.

I haven't really spent enough time thinking about this to be sure I've
captured all reasonable possibilities. And by their very nature, threat
models tend to be live as the threats morph over time.

R.