[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libltdl is inefficient and a security hazard

From: Bob Friesenhahn
Subject: Re: libltdl is inefficient and a security hazard
Date: Wed, 4 Nov 2009 19:53:22 -0600 (CST)
User-agent: Alpine 2.01 (GSO 1266 2009-07-14)

I have been doing more research on this subject. The algorithm that libltdl uses is to obtain 'old_library' and 'dlname' from the .la file.

The try_dlopen() function from ltdl.c invokes the function find_module() with both the 'old_library' and 'dlname' names. The find_module() function then proceeds to try to load using the 'old_library' and 'dlname' names. For a normal lt_dlopen(), 'advise' is NULL, so there is no guidance. Unfortunately, the invoking code does not know what type of module needs to be loaded. There is no lt_dladvise_ method which advises not to attempt to use preloaded modules so the code will aways search first with 'old_library' if it is defined.

A bit more investigation by manually editing the module .la file leads to interesting findings.

Original which causes module.a to be loaded:

  # The name of the static archive.

Modified version which nicely skips loading module.a:

  # The name of the static archive.

Modified version which causes a core dump:

  # The name of the static archive.

If I build the software with --enable-shared --disable-static then the old_library field becomes empty so the wrong search goes away.

I don't recall what method I was using to perform timings when I first noticed this issue (perhaps used trace micro-timing?) since I am not seeing a huge difference in overall application run times today due to this issue.

Time to execute a minimal command (which uses two modules) 1000 times:

--disable-shared --enable-static
real    0m7.823s
user    0m2.792s
sys     0m4.086s

--enable-shared --disable-static --with-modules
real    0m9.185s
user    0m2.982s
sys     0m5.126s

--enable-shared --enable-static --with-modules
real    0m9.268s
user    0m3.077s
sys     0m5.110s

Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]