What steps will reproduce the problem?
1. Build any Linux program with swtoolkit.
2. Run the tool "chrpath -l" on the final binaries to print their rpath, if any.
What is the expected output?
The binaries should not have an rpath unless the build rules for the product explicitly specify one.
What do you see instead?
All binaries have a default rpath equal to the value of $LIB_DIR on the build machine.
Please provide any additional information below.
The rpath is the _run-time_ library search path for a binary, i.e. the one used
by ld.so at load time to load the program. Setting it equal to the path to
build output on the build machine is nonsense. This results in the ACTUAL
SHIPPED FILES containing a reference to the build path on the build machine,
which is unnecessary, undesirable, and insecure:
* It is unnecessary because the libraries will not be located there on the
end-user's computer, so there is no need for the installed program to look at
that path.
* It is undesirable because it will result in counter-intuitive behaviour when
testing an installed product on the machine that built it because it will load
shared libraries from the build output directory instead of loading the
installed ones.
* It is insecure because an attacker could exploit a nonsense rpath on a setuid
binary to gain root access if the rpath happens to point to a directory that
the attacker can control on the end-user's machine. For example, if the product
was built in the temp directory of the build machine then the rpath on the
binary will be something like /tmp/builds/opt/lib and the attacker can create
that directory on the end-user's computer and place an altered version of libc
in it that performs some malicious action and then execute the setuid binary
with the nonsense rpath to perform that action with root access.
To fix this bug, swtoolkit simply needs to delete the "RPATH=['$LIB_DIR'],"
line in component_builders.py. If developers actually want to load libraries
from $LIB_DIR during development, they can do so by setting the LD_LIBRARY_PATH
environment variable in their shell.
Original issue reported on code.google.com by tschmelc...@chromium.org on 25 Oct 2010 at 7:14
Original issue reported on code.google.com by
tschmelc...@chromium.org
on 25 Oct 2010 at 7:14