From: Doug Evans <dje@google.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org, Tom Tromey <tromey@redhat.com>
Subject: Re: [RFA] Add $pdir as entry for libthread-db-search-path.
Date: Mon, 02 May 2011 19:51:00 -0000 [thread overview]
Message-ID: <BANLkTim6cAbsJXhN6-x4mJL_Mywyk7NN+w@mail.gmail.com> (raw)
In-Reply-To: <20110502191455.GA6481@host1.jankratochvil.net>
On Mon, May 2, 2011 at 12:14 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Sun, 01 May 2011 20:34:02 +0200, Doug Evans wrote:
>> 1) This is a patch for the FSF tree, not Fedora.
>> If this kind of security concern is the rule for the FSF tree
>
> As both libthread_db and pretty printers have the same attack surface (*) as
> DWARF expression overflow
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-4146
> where this CVE lists all public GNU/Linux vendors I do not think such security
> requirement is Fedora specific.
>
> (*) That is a foreign binary which is enough to just load into GDB.
>
> OTOH the other attack
> .gdbinit current directory execution
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=2005-1705
> also lists multiple GNU/Linux vendors and the issue is not yet fixed in FSF
> GDB. But this is IMO just still work in prograss / unfinished, not rejected:
> [RFA] .gdbinit security (revived) [incl doc]
> http://sourceware.org/ml/gdb-patches/2010-11/msg00276.html
Thanks, but I'm still stuck ...
Question for the group at large (and I it doesn't matter to me which
way we go, I just want to make forward progress ...).
Do we enforce such security concerns in FSF gdb?
And if so, let's get these issues documented (I have a pet peeve
regarding rules/issues that aren't written down).
I see some things are documented (grep for security in gdb.texinfo)
and we do have "remote system-call-allowed", but there's not yet any
mention of libthread_db or autoloading of python code (a quick scan of
the bugzilla didn't reveal anything).
Second,
If we address these security concerns what is the solution?
One proposal is on the table.
[Maintain a list of trusted paths in gdb and have a flag for
permissive/restrictive mode.
If in restrictive mode libthread_db and autoloaded python/gdbinit code
has to come from a trusted path.
I think one could take this further though.]
Last,
Do we need to address this before adding my $pdir patch?
next prev parent reply other threads:[~2011-05-02 19:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-29 3:59 Doug Evans
2011-04-29 12:36 ` Jan Kratochvil
2011-04-29 16:49 ` Doug Evans
2011-04-29 17:08 ` Jan Kratochvil
[not found] ` <BANLkTinagVcXZqvOg80eoFMnyaw9T0OYUw@mail.gmail.com>
2011-05-01 18:34 ` Doug Evans
2011-05-02 19:15 ` Jan Kratochvil
2011-05-02 19:51 ` Doug Evans [this message]
2011-05-06 18:40 ` Tom Tromey
2011-05-09 22:30 ` Doug Evans
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=BANLkTim6cAbsJXhN6-x4mJL_Mywyk7NN+w@mail.gmail.com \
--to=dje@google.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=tromey@redhat.com \
/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