[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: Thu, 5 Nov 2009 13:41:47 -0600 (CST)
User-agent: Alpine 2.01 (GSO 1266 2009-07-14)

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 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]