Looking at the binaries, we see the following:
Code: Select all
$ objdump -p xnview | grep RPATH
RPATH .:/usr/local/lib:/usr/X11R6/lib
Why is "." not OK? Because it does not do what you think. It does not add the directory where the executable is installed to the search path, but the directory from where the user executes the binary.
This is a security risk, simply because attackers can use the xnview binary to execute malicious code. If an attacker manages to get a hacked libX11.so.6 into a user's home directory, this one will be executed if the user launches xnview from his home directory.
The solution is to use "$ORIGIN" instead of "." in the RPATH. "$ORIGIN" represents the directory where the executable is installed, not the current directory. You are probably using a command similar to this one to link your executables:
Code: Select all
$ cc -o xnview 1.o 2.o 3.o ... -R.:/usr/local/lib:/usr/X11R6/lib
Code: Select all
$ cc -o xnview 1.o 2.o 3.o ... -R'$ORIGIN':/usr/local/lib:/usr/X11R6/lib
By the way, security risks related to cwd issues are not limited to the ELF RPATH feature, but include LD_LIBRARY_PATH, PATH etc., but XnView does not seem to be affected by those.
Related links:
http://www.securityfocus.com/bid/16581/discuss
http://docs.sun.com/app/docs/doc/817-19 ... l37?a=view
http://www.gentoo.org/security/en/glsa/ ... =printable
This issue is locally exploitable. Users can eliminate the problematic RPATH tag from the binaries using the "chrpath" utility, like this:
Code: Select all
$ chrpath -d /usr/bin/xnview