what about ELF rpath in Arch Linux?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

what about ELF rpath in Arch Linux?

Gerardo Exequiel Pozzi
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

Reply | Threaded
Open this post in threaded view
|

Re: what about ELF rpath in Arch Linux?

Daenyth Blank
On Fri, Mar 20, 2009 at 02:58, Gerardo Exequiel Pozzi
<[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: what about ELF rpath in Arch Linux?

Allan McRae
In reply to this post by Gerardo Exequiel Pozzi
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



Reply | Threaded
Open this post in threaded view
|

Re: what about ELF rpath in Arch Linux?

Gerardo Exequiel Pozzi
In reply to this post by Daenyth Blank
Daenyth Blank wrote:

> On Fri, Mar 20, 2009 at 02:58, Gerardo Exequiel Pozzi
> <[hidden email]> 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