Missing security fix in elf/dl-open.c?
diff mbox

Message ID 54ECB0B4.1030602@redhat.com
State New
Headers show

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

Carlos O'Donell Feb. 27, 2015, 5:07 a.m. UTC | #1
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.
Florian Weimer Feb. 27, 2015, 9:19 a.m. UTC | #2
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.
Carlos O'Donell Feb. 27, 2015, 4:43 p.m. UTC | #3
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.
Florian Weimer Feb. 27, 2015, 7:21 p.m. UTC | #4
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?
Carlos O'Donell Feb. 27, 2015, 8:41 p.m. UTC | #5
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.
Allan McRae Feb. 28, 2015, 4:23 p.m. UTC | #6
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
Carlos O'Donell Feb. 28, 2015, 5:43 p.m. UTC | #7
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
Andreas Schwab March 2, 2015, 8:41 a.m. UTC | #8
"Carlos O'Donell" <carlos@redhat.com> writes:

> Do you remember the rationale for the change in [1]?

No, sorry, I can't remember.

Andreas.

Patch
diff mbox

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;
 }