This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Avoid deadlock in malloc on backtrace
- From: Rich Felker <dalias at libc dot org>
- To: Carlos O'Donell <carlos at redhat dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>, libc-alpha at sourceware dot org
- Date: Mon, 2 Mar 2015 12:34:43 -0500
- Subject: Re: [PATCH] Avoid deadlock in malloc on backtrace
- Authentication-results: sourceware.org; auth=none
- References: <20150224100249 dot GA31871 at spoyarek dot pnq dot redhat dot com> <54EF9B9C dot 1080305 at redhat dot com> <20150302053051 dot GT19363 at vapier>
On Mon, Mar 02, 2015 at 12:30:51AM -0500, Mike Frysinger wrote:
> On 26 Feb 2015 17:18, Carlos O'Donell wrote:
> > On 02/24/2015 05:02 AM, Siddhesh Poyarekar wrote:
> > > When the malloc subsystem detects some kind of memory corruption,
> > > depending on the configuration it prints the error, a backtrace, a
> > > memory map and then aborts the process. In this process, the
> > > backtrace() call may result in a call to malloc, resulting in
> > > various kinds of problematic behavior.
> >
> > There have been various comments about this patch and I would like to
> > list some supporting rationale for this patch:
> >
> > (1) Delaying the abort is bad for security.
> >
> > Problem: The library should abort() immediately from a security perspective.
> >
> > Solution: Don't delay, call abort() immediately.
> >
> > We all agree that delaying the abort is bad from a security perspective.
> > However, the present solution is a trade-off between providing useful
> > diagnostics and *then* aborting.
>
> i think the current line glibc attempts to walk is reasonable. there are other
> funcs which are arguably more important (__chk_fail & __fortify_fail) that do a
> good amount of work (calling into __libc_message). from a security pov, that is
> all bad mojo.
And they should all be fixed.
> it might be nice if there was a configure option to enable a paranoid mode
> whereby we die as safely as possible when a failure is detected. in Gentoo we
> have a custom handler that uses direct syscalls and logs to the system logger
> before killing itself (SIGABRT & SIGKILL).
Even syscalls are unsafe on x86 unless you use custom asm. The default
mechanism goes through a syscall vdso pointer in the TCB at %gs:...
which is easily attacker-controlled after stack overflow on a non-main
thread.
The right solution is a HCF instruction or even better a sequence
like the following to avoid trapping by the application:
push $-1
push $-1
xor %edx,%edx
mov %esp,%ecx
xor %ebx,%ebx
mov $SYS_rt_sigprocmask,%eax
int $128
hlt
Rich