[PATCH v4] Improve DST handling (Bug 23102, Bug 21942, Bug 18018, Bug, 23259, CVE-2011-0536 ).

[Florian Weimer]

On 06/11/2018 04:54 AM, Carlos O'Donell wrote:
>>> I consider the following valid:
>>>
>>> [$ORIGIN/../$LIB]
>> I'm actually asking about this:
>>
>> [$LIB:$ORIGIN/../$LIB]
>>
>> Doesn't the current code reject this?
> The current code does not reject this. In fact it accepts $LIB in RPATH
> et. al. because there is no code to reject it. Only $ORIGIN has any
> restrictions.

I meant the $ORIGN part.  As far as I understand it, start will not be 
close to input for the second part containing origin (after the :), so 
this check in _dl_dst_substitute should reject it:

		      || (input != start + 1
			  || (input > start + 2 && input[-2] != ':'))))

I'm not sure that this is right.

> Should all paths get tested for trusted paths for a SUID/SGID binary?
> It seems like that's the right idea.
> 
> @@ -365,7 +383,8 @@ _dl_dst_substitute (struct link_map *l, const char *start,
>  
>    /* In SUID/SGID programs, after DST expansion the normalized
>       path must be rooted in one of the trusted directories.  */
> -  if (__glibc_unlikely (check_for_trusted)
> +  if (__glibc_unlikely (__libc_enable_secure)
> +      && l->l_type == lt_executable
>        && !is_trusted_path_normalize (result, wp - result))
>      {
>        *result = '\0';
> 
> Just drop check_for_trusted, and execute the is_trusted_path_normalize
> check for all SUID/SGID paths?

No, $ORIGIN in a trusted path is itself trusted (because you cannot 
manipulate it using hard links).  I think there are installations out 
there which depend on this.

Thanks,
Florian