Issue 18 in swtoolkit: swtoolkit embeds a nonsense rpath into all Linux binaries which an attacker could exploit to gain root access
codesite...@google.com
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 18 by tschmelc...@chromium.org: swtoolkit embeds a nonsense rpath
into all Linux binaries which an attacker could exploit to gain root access
http://code.google.com/p/swtoolkit/issues/detail?id=18
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.