[arch-general] what about ELF rpath in Arch Linux?
Hi, (first: sorry my very bad english) I see that many executables and libraries in Arch Linux don't take care about rpath in package creation step. Then when executed, the ld-linux will find libraries first in the rpath , and if fails will go to search in the cache ld.so.cache, instead of directly search here) So for example if you execute the... setfacl/getfacl/chacl (in package from core/acl, and this is the only package in [core] that have this issue with binaries) will find in libs in varius incorrects paths for example: $ readelf -d /usr/bin/getfacl | grep RPATH 0x0000000f (RPATH) Library rpath: [/home/thomas/arch/repos/core/base/acl/pkg/usr/lib] $ LD_DEBUG=libs setfacl 10323: find library=libacl.so.1 [0]; searching 10323: search (*** stripped here same paths below... ***) (RPATH from file setfacl) 10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/tls/i686/sse2/libacl.so.1 10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/tls/i686/libacl.so.1 10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/tls/sse2/libacl.so.1 10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/tls/libacl.so.1 10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/i686/sse2/libacl.so.1 10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/i686/libacl.so.1 10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/sse2/libacl.so.1 10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/libacl.so.1 10323: search cache=/etc/ld.so.cache 10323: trying file=/lib/libacl.so.1 10323: The issue here is for example if a user "thomas" in my system, create a libacl.so.1 in any of these paths, the setfacl will use them insteads of the correct libacl.so.1, and if the libacl.so.1 from thomas contain a malicious code, the user that execute it are in problem :(, root for example. OK managing rpath at build time vary from package to package, some that uses autotools/libtool, the configure script, have a --disable-rpath for controling this behavior, and other don't have. Others require rpath at build time to linking executables from the same source, and other always hardcore it (gcc -Wl,--rpath...), etc, etc. In libtool, can change a M4 macro to don't use rpath for example. There is a simple tool, to remove rpath from ELF files called chrpath [#1] (seems that cmake build system can use an aproach based on chrpath to delete rpath from ELF) For example: # /bin/ls -l /usr/bin/setfacl -rwxr-xr-x 1 root root 25052 2008-02-26 13:23 /usr/bin/setfacl # chrpath -d /usr/bin/setfacl # /bin/ls -l /usr/bin/setfacl -rwxr-xr-x 1 root root 25052 2009-03-20 01:06 /usr/bin/setfacl # LD_DEBUG=libs setfacl 11033: find library=libacl.so.1 [0]; searching 11033: search cache=/etc/ld.so.cache 11033: trying file=/lib/libacl.so.1 And now is correct and secure. The minor problem here, _and don't make much sense_ is that will do some aditionals system calls open() and stat64() for each inexistent libs on loading. Many others have /usr/lib (and many many others paths) as rpath, then when execute will look for the first library that need to load at /usr/lib/tls/i686/sse2:/usr/lib/tls/i686:/usr/lib/tls/sse2:/usr/lib/tls:/usr/lib/i686/sse2:/usr/lib/i686:/usr/lib/sse2 (and these are removed from search path for next libs), and then for all libs will look first in /usr/lib if fails do a /etc/ld.so.cache search The rpath is important when managing many versions of the same libs with same soname, for example for debuging/testing purposes. For example i see googling that in some distros (like Debian[s]) and in some BSDs the rpath is removed from all ELF files, except that in that is necessary required. Then my question: what is the position of arch-dev-team about rpath? (remember: don't take this as a mail as feature request, is just one question) Thanks in advance, I hope not to have bothered with this. Good Luck! / ¡Buena suerte! [#1] chrpath: The original home don't work http://directory.fsf.org/project/chrpath/ i use a debian mirror in my pkgbuild http://aur.archlinux.org/packages.php?ID=24818 -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
On Fri, Mar 20, 2009 at 02:58, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
Hi,
(first: sorry my very bad english)
I see that many executables and libraries in Arch Linux don't take care about rpath in package creation step. <snip>
Thanks for pointing this out, it's a pretty serious security issue. Please file a bug on http://bugs.archlinux.org about it. Probably one of the better solutions would be for makepkg to strip the rpath in the same step where it uses "strip" to remove debugging info.
Daenyth Blank wrote:
On Fri, Mar 20, 2009 at 02:58, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
Hi,
(first: sorry my very bad english)
I see that many executables and libraries in Arch Linux don't take care about rpath in package creation step. <snip>
Thanks for pointing this out, it's a pretty serious security issue. Please file a bug on http://bugs.archlinux.org about it. Probably one of the better solutions would be for makepkg to strip the rpath in the same step where it uses "strip" to remove debugging info.
You are welcomed! I created and posted a patch for personal testing purposes to use "chrpath -d" in makepkg. FS#13890 - Packaging creation and rpath issues http://bugs.archlinux.org/task/13890 http://bugs.archlinux.org/task/13890#comment41603 Good Luck! -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Gerardo Exequiel Pozzi wrote:
Hi,
(first: sorry my very bad english)
I see that many executables and libraries in Arch Linux don't take care about rpath in package creation step.
<snip> So here is what gentoo does: f=$(scanelf -qyRF '%r %p' "${D}" | grep -E "(${PORTAGE_BUILDDIR}|: |::|^ )") if [[ -n ${f} ]] ; then echo -ne '\a\n' echo "QA Notice: the following files contain insecure RUNPATH's" echo " Please file a bug about this at http://bugs.gentoo.org/" echo " For more information on this issue, kindly review:" echo " http://bugs.gentoo.org/81745" echo "${f}" echo -ne '\a\n' die "Insecure binaries detected" fi I think this should be a namcap check rather than have makepkg automatically adjust these - although I could be convinced otherwise. Sacnning my computer with readelf, I found a few other packages that this effects. There are also plenty of "Library rpath: [$ORIGIN]" which I am not sure if is bad... Anyway, it would be good if you could open a bug report about this. Allan
participants (3)
-
Allan McRae
-
Daenyth Blank
-
Gerardo Exequiel Pozzi