Re: libltdl is inefficient and a security hazard

[Bob Friesenhahn]

On Thu, 5 Nov 2009, Peter O'Gorman wrote:
> You'll see the same behavior with:
>
> #include <dlfcn.h>
>
> int main() {
>   void * a = dlopen("foo",RTLD_GLOBAL);
>   if (a) dlclose(a);
>   return 0;
> }
>
> Because $HOME/lib is in the default dynamic linker search path (see dyld(1)). 
> Using dlopen() like this is not a good idea for a secure program, best to use 
> an absolute path to avoid searching :)

Yes, of course.  I am trying to use an absolute path to avoid 
searching but the libltdl bug is causing a search to be performed 
anyway. :-(

Depending on the application using libltdl, this bug could be a mere 
annoyance, or it could be dire.

The search in un/semi-secure directories allows the exploiter to be 
successful by adding a loadable module with ".a" extension, which is 
then used rather than the intended one, which was thought to be loaded 
via explicit path.

The situation is similar to users who put un/semi-secure directories 
in their executable search path prior to secure directories. 
However, in that case, the problem is the users own fault.

The question remains how to fix libltdl without breaking the preloaded 
module functionality, and without breaking module loading on systems 
like AIX which might support ".a" files as a loadable module.  The 
problem stems from the behavior of find_module(), which invokes 
tryall_dlopen() with 'old_name' first.  If the order is reversed, then 
the security issue becomes worse since then loadable modules could be 
used to override secure preloaded modules.  The problem goes away for 
--disable-static builds because then 'old_library' is not set in the 
module.la file and there is no search for a ".a" file.

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