Message ID | 54ECB0B4.1030602@redhat.com |
---|---|
State | Superseded |
Headers |
Received: (qmail 25166 invoked by alias); 24 Feb 2015 17:13:12 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 25140 invoked by uid 89); 24 Feb 2015 17:13:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL, BAYES_00, SPF_HELO_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Message-ID: <54ECB0B4.1030602@redhat.com> Date: Tue, 24 Feb 2015 18:11:16 +0100 From: Florian Weimer <fweimer@redhat.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: GNU C Library <libc-alpha@sourceware.org> Subject: Missing security fix in elf/dl-open.c? Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit |
Commit Message
Florian Weimer
Feb. 24, 2015, 5:11 p.m. UTC
Some downstreams include this hunk in their patches related to CVE-2010-3847 and CVE-2011-0536: I can't find this in glibc master. Is the hunk above needed, or is it just hardening?
Comments
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. c.
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.
On 02/27/2015 04:19 AM, Florian Weimer wrote: > 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. Likely the `glibc-fedora-elf-ORIGIN.patch` patch in Fedora. > 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. I don't know why either. It's just wrong. The Fedora patch fixes _dl_dst_substitute which catches everything. Security cargo-cult :-) Cheers, Carlos.
On 02/27/2015 05:43 PM, Carlos O'Donell wrote: >> 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. > > Likely the `glibc-fedora-elf-ORIGIN.patch` patch in Fedora. Oooh! Does it mean we should upstream this patch instead?
On 02/27/2015 02:21 PM, Florian Weimer wrote: > On 02/27/2015 05:43 PM, Carlos O'Donell wrote: >>> 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. >> >> Likely the `glibc-fedora-elf-ORIGIN.patch` patch in Fedora. > > Oooh! Does it mean we should upstream this patch instead? Yes, and that includes reviewing exactly what it does :-) c.
On 28/02/15 06:41, Carlos O'Donell wrote: > On 02/27/2015 02:21 PM, Florian Weimer wrote: >> On 02/27/2015 05:43 PM, Carlos O'Donell wrote: >>>> 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. >>> >>> Likely the `glibc-fedora-elf-ORIGIN.patch` patch in Fedora. >> >> Oooh! Does it mean we should upstream this patch instead? > > Yes, and that includes reviewing exactly what it does :-) > Here is the original submission: https://sourceware.org/ml/libc-hacker/2010-12/msg00001.html The discussion was not very helpful. Allan
On 02/28/2015 11:23 AM, Allan McRae wrote: > On 28/02/15 06:41, Carlos O'Donell wrote: >> On 02/27/2015 02:21 PM, Florian Weimer wrote: >>> On 02/27/2015 05:43 PM, Carlos O'Donell wrote: >>>>> 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. >>>> >>>> Likely the `glibc-fedora-elf-ORIGIN.patch` patch in Fedora. >>> >>> Oooh! Does it mean we should upstream this patch instead? >> >> Yes, and that includes reviewing exactly what it does :-) >> > > Here is the original submission: > https://sourceware.org/ml/libc-hacker/2010-12/msg00001.html > > The discussion was not very helpful. Andreas, Do you remember the rationale for the change in [1]? Cheers, Carlos. [1] https://sourceware.org/ml/libc-hacker/2010-12/msg00001.html
"Carlos O'Donell" <carlos@redhat.com> writes:
> Do you remember the rationale for the change in [1]?
No, sorry, I can't remember.
Andreas.
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; }