[Bug dynamic-link/23259] Unsubstituted ${ORIGIN} remains in DT_NEEDED for AT_SECURE

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=23259

--- Comment #7 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Florian Weimer from comment #4)
> (In reply to Carlos O'Donell from comment #3)
> > The unsubstituted path is used directly to load the DT_NEEDED requirement.
> > It's only a security issue in the case that a defect in your SUID/GUID
> > application caused a malformed DT_NEEDED e.g. /bad/${ORIGIN}lib.so.
> 
> 
> Can this also happen for $ORIGIN/lib.so if $ORIGIN cannot be determined?

I will speak only about the new code right now.

In the new implementation this results in a load failure because DT_NEEDED
cannot have a DST in it for SUID/SGID.

For non-SUID/SGID it is not a load failure, but the DT_NEEDED entry will be
discarded because $ORIGIN has no replacement value, so the load might still
fail.

e.g.

 326           else if (len != 0)
 327             {
 328               /* We found a valid DST that we know about, but we could
 329                  not find a replacement value for it, therefore we
 330                  cannot use this path and discard it.  */
 331               *result = '\0';
 332               return result;
 333             }

In the old code if $ORIGIN could not be determined we should have fallen
through to this case:

e.g.

 317           else if (len > 1)
 318             {
 319               /* We cannot use this path element, the value of the
 320                  replacement is unknown.  */
 321               wp = last_elem;
 322               name += len;
 323               while (*name != '\0' && (!is_path || *name != ':'))
 324                 ++name;
 325               /* Also skip following colon if this is the first rpath
 326                  element, but keep an empty element at the end.  */
 327               if (wp == result && is_path && *name == ':' && name[1] !=
'\0')
 328                 ++name;
 329             }

Which has similar behaviour in that 'wp = last_elem', we jump back to the last
known good path in the colon separated path list, and skip 'name' forward to
the next path in the list, and work on the next path.

So I don't think it should be a problem.

-- 
You are receiving this mail because:
You are on the CC list for the bug.