rheather88 / swtoolkit

Automatically exported from code.google.com/p/swtoolkit
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

swtoolkit embeds a nonsense rpath into all Linux binaries which an attacker could exploit to gain root access #18

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
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