This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Avoid deadlock in malloc on backtrace


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]