This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug dynamic-link/21942] New: _dl_dst_substitute incorrectly handles $ORIGIN: with AT_SECURE=1


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

            Bug ID: 21942
           Summary: _dl_dst_substitute incorrectly handles $ORIGIN: with
                    AT_SECURE=1
           Product: glibc
           Version: 2.26
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: fweimer at redhat dot com
  Target Milestone: ---
             Flags: security-

With an RPATH entry "$ORIGIN:./", _dl_dst_substitute checks the wrong path for
trustworthiness, resulting in an incorrect library search path.

I patched logging into elf/dl-load.c and set __libc_enable_secure
unconditionally, and got this:

     12051:     _dl_dst_substitute: looking at: $ORIGIN:./
     12051:     is_dst: $ORIGIN:./ found
     12051:     _dl_dst_substitute: $ substitution: /root/origin/.
     12051:     _dl_dst_substitute: remaining string: :./
     12051:     _dl_dst_substitute: looking at: :./
     12051:     _dl_dst_substitute: looking at: ./
     12051:     _dl_dst_substitute: looking at: /
     12051:     is_trusted_path_normalize: path start: [[/root/origin/.:./]]
(17)
     12051:     is_trusted_path_normalize: path transformed:
[[/root/origin/.:./]]
     12051:     is_trusted_path_normalize: npath: [[/root/origin/.:./]]
     12051:     is_trusted_path_normalize: path is NOT trusted
     12051:     final path element is not trusted: /root/origin/.:./
     12051:     _dl_dst_substitute result: 

The log indicates that dl_dst_substitute performs $ORIGIN expansion, but the
check for the trustworthiness of the expanded component does not stop at the
next ':' character.  Instead is_trusted_path_normalize is called with a
substring which includes the next path element as well.  The cause for that we
do not look at name[0] to recognize the ':', only name[1]:

      else
        {
          *wp++ = *name++;
          if (is_path && *name == ':')

I'm not sure if there is a trivial fix for this.  The execution flow is very
complicated.

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]