This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Missing security fix in elf/dl-open.c?
- From: Florian Weimer <fweimer at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 27 Feb 2015 10:19:51 +0100
- Subject: Re: Missing security fix in elf/dl-open.c?
- Authentication-results: sourceware.org; auth=none
- References: <54ECB0B4 dot 1030602 at redhat dot com> <54EFFBA6 dot 4070108 at redhat dot com>
On 02/27/2015 06:07 AM, Carlos O'Donell wrote:
> On 02/24/2015 12:11 PM, Florian Weimer wrote:
>> Some downstreams include this hunk in their patches related to
>> CVE-2010-3847 and CVE-2011-0536:
>>
>> Index: glibc-2.12-2-gc4ccff1/elf/dl-object.c
>> ===================================================================
>> --- glibc-2.12-2-gc4ccff1.orig/elf/dl-object.c
>> +++ glibc-2.12-2-gc4ccff1/elf/dl-object.c
>> @@ -214,6 +214,9 @@ _dl_new_object (char *realname, const ch
>> out:
>> new->l_origin = origin;
>> }
>> + else if (INTUSE(__libc_enable_secure) && type == lt_executable)
>> + /* The origin of a privileged program cannot be trusted. */
>> + new->l_origin = (char *) -1;
>>
>> return new;
>> }
>>
>> I can't find this in glibc master. Is the hunk above needed, or is it
>> just hardening?
>
> Seems like additional hardening to me, and it could break real applications.
I don't understand much about ld.so, so here's what I guess the code
does: It clears the origin of the main program if running as AT_SECURE.
However, something else already does this in Fedora 20
(glibc-2.20-7.fc21.x86_64, which lacks this patch as well AFAICT). I
created a SUID binary with an $ORIGIN RPATH, and it is ignored, but only
when actually running SUID.
It's also not clear to me why you would want to do this (whatever
happens here) only for the main program, and not for other objects.
--
Florian Weimer / Red Hat Product Security