From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19921 invoked by alias); 16 Nov 2009 15:40:56 -0000 Received: (qmail 19912 invoked by uid 22791); 16 Nov 2009 15:40:55 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 16 Nov 2009 15:39:51 +0000 Received: from zps75.corp.google.com (zps75.corp.google.com [172.25.146.75]) by smtp-out.google.com with ESMTP id nAGFdmgO026518 for ; Mon, 16 Nov 2009 15:39:48 GMT Received: from pxi40 (pxi40.prod.google.com [10.243.27.40]) by zps75.corp.google.com with ESMTP id nAGFdjgG012585 for ; Mon, 16 Nov 2009 07:39:45 -0800 Received: by pxi40 with SMTP id 40so784020pxi.13 for ; Mon, 16 Nov 2009 07:39:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.115.101.5 with SMTP id d5mr7438242wam.23.1258385985264; Mon, 16 Nov 2009 07:39:45 -0800 (PST) In-Reply-To: References: <20091115173429.GB23483@caradoc.them.org> <200911152148.nAFLmYPK018249@glazunov.sibelius.xs4all.nl> Date: Mon, 16 Nov 2009 15:40:00 -0000 Message-ID: <8ac60eac0911160739x6bbc1237w49556339ed855e66@mail.gmail.com> Subject: Re: RFC: Longjmp vs LD_POINTER_GUARD revisited From: Paul Pluzhnikov To: "Frank Ch. Eigler" Cc: Mark Kettenis , joseph@codesourcery.com, drow@false.org, gdb-patches@sourceware.org, pedro@codesourcery.com, uweigand@de.ibm.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-11/txt/msg00363.txt.bz2 On Mon, Nov 16, 2009 at 7:13 AM, Frank Ch. Eigler wrote: > Well, it's nothing personal. =A0If 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. >=A0Maybe 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. --=20 Paul Pluzhnikov