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

  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?
  

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.