This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: Longjmp vs LD_POINTER_GUARD revisited
> Date: Mon, 16 Nov 2009 07:39:45 -0800
> From: Paul Pluzhnikov <ppluzhnikov@google.com>
>
> On Mon, Nov 16, 2009 at 7:13 AM, Frank Ch. Eigler <fche@redhat.com> wrote:
>
> > Well, it's nothing personal. ?If glibc made it trivial decrypt this
> > stuff on demand, it'd be just as easy for an attacker.
>
> That's exactly my point: the process itself can trivially discover the
> problem by executing two setjmps with known resume addresses (an
> implementation I did in my previous job (for a Valgrind-like checker)
> took less than 20 lines of assembly), so I wonder how much of a
> deterrent this really is.
Well, the whole purpose of encrypting the setjmp buffer this way is to
prevent an attacker from longjmp-ing to "shellcode" by overwriting the
setjmp buffer by exploiting some sort of buffer overflow. The fact
that an attacker can trivially write some shellcode to figure out the
cookie doesn't really help him because he'll still have to find a way
to execute that shellcode.
At the same time, this means that there's little benefit from coming
up with clever encrypting algorithms (a simple XOR is probably good
enough) and going through extreme lengths to hide the cookie. So I
don't think an agreed upon interface between glibc and GDB, on how to
find the cookie and which encrypting algorithm is used would have a
significant impact on security.
> >?Maybe this is a case for something akin to libthread_db.
>
> Hmm, libc_db to subsume libthread_db, and answer all kinds of
> questions about glibc internals; wouldn't GDB's life be easier! OTOH,
> if the sysadmin is not careful to remove libc_db from a production
> system, then the attacker could just dlopen libc_db and hack away.
I'm not sure something similar to libthread_db is such a terribly goo
idea; it tends to be a bitch for cross-debugging. As to the security
implications of having such a libc_db, see my argument above.