Re: libltdl is inefficient and a security hazard

[Bob Friesenhahn]

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.
  old_library='module.a'

Modified version which nicely skips loading module.a:

  # The name of the static archive.
  old_library=''

Modified version which causes a core dump:

  # The name of the static archive.
  old_library=

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
--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/