current directory (".") in ELF RPATH tag is a secu

[Guest]

The XnView Linux binaries are using an ELF feature that allows to specify additional library search directories in the executable itself. This is usually not a problem, but the XnView Linux binaries do it in a way that can be a security risk.

Looking at the binaries, we see the following:

Code: Select all

$ objdump -p xnview | grep RPATH
  RPATH       .:/usr/local/lib:/usr/X11R6/lib

This means that libraries are first searched in the current directory ("." -> not OK, see below), then in /usr/local/lib (OK), followed by /usr/X11R6/lib (OK) and afterwards in the standard directories (OK, of course).

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

Use something like this instead:

Code: Select all

$ cc -o xnview 1.o 2.o 3.o ... -R'$ORIGIN':/usr/local/lib:/usr/X11R6/lib

It is very important to quote "$ORIGIN" correctly, otherwise the shell will expand it to the empty string with the result that the current directory is again added to the RPATH because empty strings before the first ":", between two ":" and after the last ":" have the same effect as ".".

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