Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Willgerodt, Felix" <felix.willgerodt@intel.com>
To: Simon Marchi <simark@simark.ca>,
	Andrew Burgess <aburgess@redhat.com>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Cc: Siddhesh Poyarekar <siddhesh@redhat.com>
Subject: RE: [RFC] Adding a SECURITY policy for GDB
Date: Thu, 9 Nov 2023 14:35:07 +0000	[thread overview]
Message-ID: <MN2PR11MB4566AD68135086BE570C7EE88EAFA@MN2PR11MB4566.namprd11.prod.outlook.com> (raw)
In-Reply-To: <e5ad38d4-787c-4c0d-9df7-99f940376cf7@simark.ca>

> >   While GDB is intended to be robust against untrusted binaries, it is
> >   not responsible for arbitrary code execution on a system.  As a
> >   result, any bugs exposed by untrusted binaries will be accepted and
> >   treated with appropriate urgency, but will not be considered
> >   security issues.  This applies to local as well as remote debugging;
> >   any bugs in gdbserver, exposed by untrusted binaries will be
> >   accepted and treated with appropriate urgency, but will not be
> >   considered security issues.
> 
> My opinion would have been that just loading a file in GDB just to
> inspect it statically should be a safe thing to do, even with a
> malicious binary.  It's possible to do in theory, by being defensive and
> very careful of everything we read.
> 
> In practice, I understand that it might not be a realistic goal, given
> the complexity and the current state of BFD / GDB.  And since most of
> the CVEs you got (IIUC) were of this kind, that wouldn't help you much.
> So, I'm fine with that you have, given that I'm not the one who has to
> deal with these annoyances.
> 
> Simon

First off thanks for doing this Andrew! I am very much in favor of your
proposed SECURITY file.

Can the file explicitly mention the static inspection case that Simon
brought up?
To me, it is pretty clear that untrusted binaries that you run in GDB are
out of scope, as you already actively chose to run untrusted code.
However I think the static case is much less clear for many people.
Being more explicit about it could help with that.

FYI, the binutils file has written this:

"Bugs in inspection tools (eg readelf, nm objdump) will not be considered
to be security bugs, since they do not create executable output
files."
(I personally think their reasoning is a bit vague, but that is another topic.)

Felix
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

  parent reply	other threads:[~2023-11-09 14:35 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-06 13:26 Andrew Burgess
2023-11-06 18:55 ` Kevin Buettner
2023-11-06 19:34 ` Simon Marchi
2023-11-06 20:09   ` Siddhesh Poyarekar
2023-11-06 20:15     ` Simon Marchi
2023-11-07 12:17       ` Siddhesh Poyarekar
2023-11-07 14:22         ` Simon Marchi
2023-11-09 14:35   ` Willgerodt, Felix [this message]
2023-11-16 17:19   ` Andrew Burgess
2023-11-16 17:27     ` Paul Koning
2023-11-16 21:35       ` Siddhesh Poyarekar
2023-12-08 15:05 ` Andrew Burgess
2023-12-09 10:55   ` Eli Zaretskii
2024-02-04 15:32     ` Andrew Burgess
2024-02-04 17:18       ` Eli Zaretskii
2024-02-04 17:43         ` Andreas Schwab
2024-02-04 18:56           ` Eli Zaretskii
2024-02-05 11:06         ` Andrew Burgess
2023-12-12  7:27   ` Willgerodt, Felix
2024-02-04 15:36   ` [V3] " Andrew Burgess
2024-02-18 13:55     ` Andrew Burgess
2024-03-27 11:00       ` [V4] " Andrew Burgess
2024-04-08 11:01         ` [V5] " Andrew Burgess
2024-04-09 20:30           ` Tom Tromey
2024-04-10 10:22           ` Willgerodt, Felix
2024-04-26 15:44             ` Andrew Burgess
2024-02-05 21:01   ` Tom Tromey
2024-02-09 15:59     ` Andrew Burgess
2024-02-12 16:43   ` Guinevere Larsen
2024-02-12 17:06     ` Siddhesh Poyarekar
2024-02-14 15:03       ` Andrew Burgess

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=MN2PR11MB4566AD68135086BE570C7EE88EAFA@MN2PR11MB4566.namprd11.prod.outlook.com \
    --to=felix.willgerodt@intel.com \
    --cc=aburgess@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=siddhesh@redhat.com \
    --cc=simark@simark.ca \
    /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