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

Questions, suggestions, and answers for XnView on all Un*x platforms (Linux, HP-UX, AIX, ...)

Moderators: XnTriq, xnview


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

Post by 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 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: ... l37?a=view ... =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