public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>
To: "Petr Tesařík" <petr@tesarici.cz>, gdb@sourceware.org
Subject: Re: Threat model for GNU Binutils
Date: Fri, 14 Apr 2023 16:31:58 +0100	[thread overview]
Message-ID: <539b2e82-b084-784b-673b-b175638454f8@foss.arm.com> (raw)
In-Reply-To: <20230414172538.1ddee8d5@meshulam.tesarici.cz>



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.

  reply	other threads:[~2023-04-14 15:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-14 13:12 Richard Earnshaw
2023-04-14 14:08 ` Siddhesh Poyarekar
2023-04-14 14:41   ` Richard Earnshaw
2023-04-14 15:25     ` Petr Tesařík
2023-04-14 15:31       ` Richard Earnshaw [this message]
2023-04-14 15:50         ` Phi Debian
2023-04-14 16:45         ` Petr Tesařík
2023-04-17 16:17     ` Siddhesh Poyarekar
2023-04-17 16:22       ` Siddhesh Poyarekar
2023-04-14 15:07   ` Richard Earnshaw

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=539b2e82-b084-784b-673b-b175638454f8@foss.arm.com \
    --to=richard.earnshaw@foss.arm.com \
    --cc=gdb@sourceware.org \
    --cc=petr@tesarici.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).