public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "carlos at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/12189] __stack_chk_fail should not attempt a backtrace
Date: Fri, 30 Aug 2013 19:12:00 -0000	[thread overview]
Message-ID: <bug-12189-131-TCCKKRi67i@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-12189-131@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=12189

--- Comment #8 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Rich Felker from comment #7)
> I would like an even more extreme fix, removing all possibility of output
> from __*_chk_fail and having them immediately abort() or similar (but see
> the caveats that follow). Once the program state is compromised, any further
> execution could turn a DoS vulnerability into a code-execution one. Even
> things like the vdso syscall pointer at %gs:whatever should not be trusted
> at this point, because you already have evidence that the program state is
> compromised; a stack-based buffer overflow on a non-main thread could easily
> reach into the TCB.
> 
> In musl, we have an inline function called a_crash() for things like this;
> it's defined as __asm__ __volatile__ ("hlt"); on x86 and intended to be
> defined analogously on other archs, although right now it's just *(volatile
> char *)0=0; on most.

We have ABRT_INSTRUCTION in glibc for all targets and we could use it in this
case. I don't disagree with your rationale behind why glibc shouldn't print a
backtrace, but it still needs a champion to post the patch on libc-alpha and
get consensus. It seems like we would likely have 2 or 3 immediate ACKs for
this patch. I'm leaving it up to Kees to push it forward.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


  parent reply	other threads:[~2013-08-30 19:12 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-03 21:20 [Bug libc/12189] New: " kees at outflux dot net
2010-11-04  1:04 ` [Bug libc/12189] " drepper.fsp at gmail dot com
2010-11-04  9:52 ` pasky at suse dot cz
2010-11-04 11:25 ` drepper.fsp at gmail dot com
2013-08-29 21:46 ` kees at outflux dot net
2013-08-29 21:47 ` kees at outflux dot net
2013-08-29 21:53 ` kees at outflux dot net
2013-08-30 17:56 ` carlos at redhat dot com
2013-08-30 18:26 ` bugdal at aerifal dot cx
2013-08-30 19:12 ` carlos at redhat dot com [this message]
2013-08-30 20:52 ` joseph at codesourcery dot com
2013-08-30 21:02 ` joseph at codesourcery dot com
2013-09-03 20:43 ` carlos at redhat dot com
2014-03-30  0:42 ` sstewartgallus00 at mylangara dot bc.ca
2014-06-13 10:58 ` fweimer at redhat dot com
2014-06-13 12:18 ` fweimer at redhat dot com
2015-02-24 12:46 ` [Bug libc/12189] __stack_chk_fail should not attempt a backtrace (CVE-2010-3192) fweimer at redhat dot com
2015-02-24 12:48 ` fweimer at redhat dot com
2015-04-28 19:18 ` carlos at redhat dot com

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=bug-12189-131-TCCKKRi67i@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=glibc-bugs@sourceware.org \
    /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).