[Bug libc/12189] New: __stack_chk_fail should not attempt a backtrace

[Bug libc/12189] New: __stack_chk_fail should not attempt a backtrace

[kees at outflux dot net]

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

           Summary: __stack_chk_fail should not attempt a backtrace
           Product: glibc
           Version: 2.12
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper.fsp@gmail.com
        ReportedBy: kees@outflux.net


Currently, the _chk functions when aborting will attempt to produce a
backtrace. This should be disabled for __stack_chk_fail since by definition the
stack is corrupted. This at least leads to segfaults in the backtracer.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12189] __stack_chk_fail should not attempt a backtrace

[drepper.fsp at gmail dot com]

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

Ulrich Drepper <drepper.fsp at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME

--- Comment #1 from Ulrich Drepper <drepper.fsp at gmail dot com> 2010-11-04 01:03:56 UTC ---
The information can be useful and that's reason enough.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12189] __stack_chk_fail should not attempt a backtrace

[pasky at suse dot cz]

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

Petr Baudis <pasky at suse dot cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |pasky at suse dot cz
         Resolution|WORKSFORME                  |

--- Comment #2 from Petr Baudis <pasky at suse dot cz> 2010-11-04 09:51:45 UTC ---
I'd like to reopen this for another bit - this actually has CVE 2010-3192
assigned and is considered a security bug by some, leaking information in case
the attacker can just trigger fortified source protection. I'm personally
rather ambivalent on whether this should be fixed, but the argument does make
sense. If we would just always print the information if it was useful, we
should have a default SIGSEGV and SIGABRT handlers printing backtrace too. :-)

C.f. http://seclists.org/fulldisclosure/2010/Apr/399,
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-3192

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12189] __stack_chk_fail should not attempt a backtrace

[drepper.fsp at gmail dot com]

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

Ulrich Drepper <drepper.fsp at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #3 from Ulrich Drepper <drepper.fsp at gmail dot com> 2010-11-04 11:25:15 UTC ---
No, it makes no sense.  First, it's logged to the console.  Second, if you can
trigger it you already know where in the program you are.  Third, there is no
address given for the values printed.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12189] __stack_chk_fail should not attempt a backtrace

[kees at outflux dot net]

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

Kees Cook <kees at outflux dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |---

--- Comment #4 from Kees Cook <kees at outflux dot net> ---
Various people continue to contact me about fixing this problem in glibc. It's
a real issue that makes offline analysis of stack smash detection harder to
handle due to segfaults while unwinding corrupt stacks.

I've attached a quick hack to make this work better.

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

[Bug libc/12189] __stack_chk_fail should not attempt a backtrace

[kees at outflux dot net]

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

--- Comment #5 from Kees Cook <kees at outflux dot net> ---
Created attachment 7175
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7175&action=edit
patch to stop stack unwinds on stack smashing aborts

This has been carried by Ubuntu for some time now.

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

[Bug libc/12189] __stack_chk_fail should not attempt a backtrace

[kees at outflux dot net]

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

Kees Cook <kees at outflux dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|drepper.fsp at gmail dot com       |unassigned at sourceware dot org

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

[Bug libc/12189] __stack_chk_fail should not attempt a backtrace

[carlos at redhat dot com]

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

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #6 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Kees Cook from comment #5)
> Created attachment 7175 [details]
> patch to stop stack unwinds on stack smashing aborts
> 
> This has been carried by Ubuntu for some time now.

This patch needs to be discussed on libc-alpha and consensus reached on the
change. Once we have consensus you'll be able to get an ACK from developers and
checkin whatever was decided upon. Until then this is likely to go unnoticed by
the core developers. Like in Linux and other projects, these kinds of changes
need to be championed.

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

[Bug libc/12189] __stack_chk_fail should not attempt a backtrace

[bugdal at aerifal dot cx]

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

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #7 from Rich Felker <bugdal at aerifal dot cx> ---
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.

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

[Bug libc/12189] __stack_chk_fail should not attempt a backtrace

[carlos at redhat dot com]

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.

[Bug libc/12189] __stack_chk_fail should not attempt a backtrace

[joseph at codesourcery dot com]

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

--- Comment #9 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Fri, 30 Aug 2013, carlos at redhat dot com wrote:

> We have ABRT_INSTRUCTION in glibc for all targets and we could use it in this

I see no sign of ABORT_INSTRUCTION for aarch64, alpha, am33 or arm.

(ARM has such a permanently undefined instruction - "udf #0" - but it 
appears gas doesn't know the mnemonic for it, so you'd need to encode it 
with ".inst" / ".inst.n" / ".inst.w".)

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

[Bug libc/12189] __stack_chk_fail should not attempt a backtrace

[joseph at codesourcery dot com]

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

--- Comment #10 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
(Binutils bug 15914 filed for the lack of gas support for UDF on ARM.)

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

[Bug libc/12189] __stack_chk_fail should not attempt a backtrace

[carlos at redhat dot com]

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

--- Comment #11 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to joseph@codesourcery.com from comment #9)
> On Fri, 30 Aug 2013, carlos at redhat dot com wrote:
> 
> > We have ABRT_INSTRUCTION in glibc for all targets and we could use it in this
> 
> I see no sign of ABORT_INSTRUCTION for aarch64, alpha, am33 or arm.

It is a QoI issue, it wouldn't be hard to add something for all of these
machines.

I would like to make it mandatory that all machines implement
ABORT_INSTRUCTION, but haven't suggested it yet.

It's the only way in which glibc aborts in situations where a function call
can't be made or error conditions have forced us into a fallback e.g.
check_one_fd, abort, _exit.

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

[Bug libc/12189] __stack_chk_fail should not attempt a backtrace

[sstewartgallus00 at mylangara dot bc.ca]

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

Steven Stewart-Gallus <sstewartgallus00 at mylangara dot bc.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sstewartgallus00@mylangara.
                   |                            |bc.ca

--- Comment #12 from Steven Stewart-Gallus <sstewartgallus00 at mylangara dot bc.ca> ---
It might be possible to fork and execute a second uncorrupted process but
simply aborting is safer and lazier. Something like the following might work:

#include <signal.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

/*
 * In a real implementation this would be a real crash reporting
 * program. It would use /proc to examine debugging information such
 * as the command line. It could also do ptrace debugger stuff. It
 * could also be set by a command line option.
 */
#define CRASH_REPORTER "/bin/echo"

void stack_overflow(void);

int main()
{
    stack_overflow();
}

void stack_overflow(void)
{
    /*
     * As soon as possible give control over to a fresh crash reporter
     * instance. If any bad things happen abort immmediately and don't
     * risk compromise due to an attack from an enemy.
     */

    /*
     * Fork a copy of the program to be debugged from the crash
     * reporter instance. The copy of the program must be the child
     * because certain systems are hardened to only allow parents of
     * the processes to do certain debugging tasks.
     */
    pid_t child = fork();
    if (-1 == child) {
        abort();
    }

    if (0 == child) {
        raise(SIGSTOP);
    }

    /* Don't bother with sprintf to minimize the chance of attacks. */
    char child_string[sizeof child + 1];
    memcpy(child_string, &child, sizeof child);
    child_string[sizeof child] = '\0';

    /*
     * execve the crash reporter to use the thinnest possible wrapper
     * over the system call.
     */
    char * argv[] = {
        (char *) CRASH_REPORTER,
        child_string,
        NULL
    };
    char * envp[] = { NULL };
    execve(CRASH_REPORTER, argv, envp);
    abort();
}

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

[Bug libc/12189] __stack_chk_fail should not attempt a backtrace

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

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

[Bug libc/12189] __stack_chk_fail should not attempt a backtrace

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://sourceware.org/bugz
                   |                            |illa/show_bug.cgi?id=16159

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

[Bug libc/12189] __stack_chk_fail should not attempt a backtrace (CVE-2010-3192)

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|__stack_chk_fail should not |__stack_chk_fail should not
                   |attempt a backtrace         |attempt a backtrace
                   |                            |(CVE-2010-3192)
              Alias|                            |CVE-2010-3192

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

[Bug libc/12189] __stack_chk_fail should not attempt a backtrace (CVE-2010-3192)

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security+

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

[Bug libc/12189] __stack_chk_fail should not attempt a backtrace (CVE-2010-3192)

[carlos at redhat dot com]

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

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |SUSPENDED

--- Comment #13 from Carlos O'Donell <carlos at redhat dot com> ---
This issue is suspended until someone sorts out a solution, and posts to
libc-alpha to gain consensus on which direction to take.

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