Bug 537941 (CVE-2009-3736) - CVE-2009-3736 libtool: libltdl may load and execute code from a library in the current directory
Summary: CVE-2009-3736 libtool: libltdl may load and execute code from a library in th...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2009-3736
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL: http://web.nvd.nist.gov/view/vuln/det...
Whiteboard:
Depends On: 538180 538181 538182 538184 538185 538191 538510 540123 543559 545572 545573 545574 545575 545576 545584 545586 545587 545588 545665 545666 545669 545670 545671 545672 545673 546410 563968 563969 563971 563972 563973 563974 563975 563976 563978 563980 563981 563983 583076 833928
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-11-16 20:59 UTC by Vincent Danen
Modified: 2021-09-13 19:42 UTC (History)
19 users (show)

Fixed In Version: libtool 2.2.6b
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-03-31 10:10:07 UTC
Embargoed:


Attachments (Terms of Use)
test suite for libltdl (844 bytes, application/x-bzip2)
2009-11-19 18:33 UTC, Vincent Danen
no flags Details
patch to fix the flaw in libtool 2.x (4.97 KB, patch)
2009-11-19 18:34 UTC, Vincent Danen
no flags Details | Diff
Local copy of Gentoo patch for CVE-2009-3736 for GraphicsMagick-1.3.7 (846 bytes, patch)
2009-12-02 16:14 UTC, Jan Lieskovsky
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2009:1646 0 normal SHIPPED_LIVE Moderate: libtool security update 2009-12-08 19:04:31 UTC
Red Hat Product Errata RHSA-2010:0039 0 normal SHIPPED_LIVE Moderate: gcc and gcc4 security update 2010-01-13 17:34:46 UTC

Description Vincent Danen 2009-11-16 20:59:20 UTC
CERT reported a vulnerability in libltdl (part of libtool) where it could, in some cases, load and execute code from a library in the current directory (or the system's shared library search path) instead of the library that was requested with an absolute path.  Systems which don't enforce specific naming for loadable objects, or which search for loadable objects in insecure directories (such as the current working directory), or don't require that loadable objects be signed in some way or have ttheir execute bits set, are particularly vulnerable, and are trivial to exploit via an uploaded file.

All versions of libtool are vulnerable to this issue; 2.2.6b was released which corrects it.  CERT indicates that the vulnerability is "trivially exploitable" on Windows, OS X, HP-UX, and True 64 UNIX since they search for modules in the current directory.  They also indicate the vulnerability is limited to software that uses libltdl to load libraries that have an associated .la file with a non-empty old_library field.

Looking at upstream, I believe the following two git commits are required to fix the problem:

http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=e91f7b960032074a55fc91273c1917e3082b5338
http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=3580cddcea7eec5c07cf69e8adbe14ccf94dccc1

The upstream announcement is here:

http://lists.gnu.org/archive/html/libtool/2009-11/msg00059.html

The CVE name CVE-2009-3736 has been assigned to this issue.

Comment 7 Vincent Danen 2009-11-17 16:28:37 UTC
This has a lesser impact on Linux than it does on some other operating systems due to the fact that Linux uses a reasonably secure search path for shared libraries and modules by default, however it can be prefixed with a user-provided LD_LIBRARY_PATH environment variable.  A Linux user could be at risk if LD_LIBRARY_PATH contains an insecure directory.

If libltdl is provided with a module.la or libfoo.la file, it will obtain the "old_library" specification from the discovered .la file and will attempt to dlopen with that name (i.e. "archive.a"); this search is done with the bare name rather than a qualified (defined) path.  This could result in applications that were carefully designed to be secure being rendered insecure.  This, however, is only a problem if a static archive was built, so libraries and applications build with --disable-static are not impacted.  On Red Hat Enterprise Linux, most static archives are only provided via -devel packages, although there are a number of notable exceptions (such as gcc, binutils, dev86, and so forth).

As well, lt_dlopen() and dl_openext() with a bare specification and without an absolute path ("module.la" or "libfoo.la") will use a reasonably secure path, but it also checks the current directory for .la files also.  dl_openext() is documented to find the module by appending various extensions: it will append .la and if it finds a .la file, it will use it, otherwise it will retry with .so, however checking the current directory is _not_ documented behaviour.

On Linux, this issue is more difficult to exploit than on some other systems, due to the default of searching a reasonably secure search path (unless LD_LIBRARY_PATH is defined).  Packages using libltdl but with no .la files are not affected.  Packages using libltdl and .la files that contain "old_library=''" are not affected.  Packages using libltdl and .la files that contain "old_library='something.a'" will do a dlopen("something.a"), which may or may not be a problem, due to the reasons outlined above.

Comment 10 Vincent Danen 2009-11-17 17:29:24 UTC
The following packages contain embedded libltdl.  Of them, only freeradius and pspell have a dependency on libltdl.so, so the rest are not linked to the system libltdl and would likely need to be updated as well.

Results in Tag: rhel3

arts-1.1.3-2.4: (source) arts-1.1.3.tar.bz2: arts-1.1.3/libltdl/ltdl.c
compat-gcc-7.3-2.96.128: (source) libgcj-2.96.tar.bz2: libgcj/libjava/libltdl/ltdl.c
freeradius-1.0.1-2.RHEL3.4: (source) freeradius-1.0.1.tar.gz: freeradius-1.0.1/libltdl/ltdl.c
gcc-3.2.3-59: (source) gcc-3.2.3-20040701.tar.bz2: gcc-3.2.3-20040701/libjava/libltdl/ltdl.c
gcc-ssa-3.5ssa-0.20030801.48: (source) gcc-3.5ssa-20030617.tar.bz2: gcc/libjava/libltdl/ltdl.c
guile-1.6.4-8.30.1: (source) guile-1.6.4.tar.gz: guile-1.6.4/libguile-ltdl/guile-ltdl.c
guile-1.6.4-8.30.1: (source) guile-1.6.4.tar.gz: guile-1.6.4/libguile-ltdl/raw-ltdl.c
guile-1.6.4-8.30.1: (source) guile-1.6.4.tar.gz: guile-1.6.4/libguile-ltdl/upstream/ltdl.c
guile-1.6.4-8.30.1: (source) guile-1.6.4.tar.gz: guile-1.6.4/libguile-ltdl/upstream/ltdl.c.diff
ImageMagick-5.5.6-25: (source) ImageMagick-5.5.6.tar.bz2: ImageMagick-5.5.6/ltdl/ltdl.c
kdelibs-3.1.3-6.12: (source) kdelibs-3.1.3.tar.bz2: kdelibs-3.1.3/libltdl/ltdl.c
libtool-1.4.3-6: (source) libtool-1.4.3.tar.gz: libtool-1.4.3/libltdl/ltdl.c
pspell-0.12.2-16.1: (source) pspell-.12.2.tar.gz: pspell-.12.2/libltdl/ltdl.c
unixODBC-2.2.8-2.3.0.2: (source) unixODBC-2.2.8.tar.gz: unixODBC-2.2.8/libltdl/ltdl.c

Results in Tag: rhel4

arts-1.3.1-2: (source) arts-1.3.1.tar.bz2: arts-1.3.1/libltdl/ltdl.c
compat-gcc-32-3.2.3-47.3: (source) gcc-3.2.3-20040701.tar.bz2: gcc-3.2.3-20040701/libjava/libltdl/ltdl.c
freeradius-1.0.1-3.RHEL4.5: (source) freeradius-1.0.1.tar.gz: freeradius-1.0.1/libltdl/ltdl.c
gcc-3.4.6-11: (source) gcc-3.4.6-20060404.tar.bz2: gcc-3.4.6-20060404/libjava/libltdl/ltdl.c
gcc4-4.1.2-44.EL4: (source) gcc-4.1.2-20090126.tar.bz2: gcc-4.1.2-20090126/libjava/libltdl/ltdl.c
guile-1.6.4-14: (source) guile-1.6.4.tar.gz: guile-1.6.4/libguile-ltdl/guile-ltdl.c
guile-1.6.4-14: (source) guile-1.6.4.tar.gz: guile-1.6.4/libguile-ltdl/raw-ltdl.c
guile-1.6.4-14: (source) guile-1.6.4.tar.gz: guile-1.6.4/libguile-ltdl/upstream/ltdl.c
guile-1.6.4-14: (source) guile-1.6.4.tar.gz: guile-1.6.4/libguile-ltdl/upstream/ltdl.c.diff
ImageMagick-6.0.7.1-20.el4: (source) ImageMagick-6.0.7-1.tar.bz2: ImageMagick-6.0.7/ltdl/ltdl.c
kdelibs-3.3.1-11.el4: (source) kdelibs-3.3.1.tar.bz2: kdelibs-3.3.1/libltdl/ltdl.c
lam-7.1.2-15.el4: (source) lam-7.1.2-rh1.tar.bz2: lam-7.1.2-rh1/share/libltdl/ltdl.c
libtool-1.5.6-4.EL4.2: (source) libtool-1.5.6.tar.gz: libtool-1.5.6/libltdl/ltdl.c
openmpi-1.2.8-4.el4: (source) openmpi-1.2.8.tar.bz2: openmpi-1.2.8/opal/libltdl/ltdl.c
openmpi11-1.1.5-7.el4: (source) openmpi-1.1.5.tar.bz2: openmpi-1.1.5/opal/libltdl/ltdl.c
openmpi11-1.1.5-7.el4: (source) openmpi-1.1.5.tar.bz2: openmpi-1.1.5/opal/win32/generated_source/ltdl.c
unixODBC-2.2.11-1.RHEL4.1: (source) unixODBC-2.2.11.tar.gz: unixODBC-2.2.11/libltdl/ltdl.c
xmlsec1-1.2.6-3: (source) xmlsec1-1.2.6.tar.gz: xmlsec1-1.2.6/src/ltdl.c
xmlsec1-1.2.6-3: (source) xmlsec1-1.2.6.tar.gz: xmlsec1-1.2.6/src/xmlsec-ltdl.c

Results in Tag: rhel5

arts-1.5.4-1: (source) arts-1.5.4.tar.bz2: arts-1.5.4/libltdl/ltdl.c
compat-gcc-32-3.2.3-61: (source) gcc-3.2.3-20040701.tar.bz2: gcc-3.2.3-20040701/libjava/libltdl/ltdl.c
compat-gcc-34-3.4.6-4: (source) gcc-3.4.6-20060404.tar.bz2: gcc-3.4.6-20060404/libjava/libltdl/ltdl.c
freeradius-1.1.3-1.4.el5: (source) freeradius-1.1.3.tar.bz2: freeradius-1.1.3/libltdl/ltdl.c
gcc-4.1.2-46.el5: (source) gcc-4.1.2-20080825.tar.bz2: gcc-4.1.2-20080825/libjava/libltdl/ltdl.c
gcc44-4.4.0-6.el5: (source) gcc-4.4.0-20090514.tar.bz2: gcc-4.4.0-20090514/libjava/libltdl/ltdl.c
gphoto2-2.2.0-3.el5: (source) libgphoto2-2.2.1.tar.bz2: libgphoto2-2.2.1/libgphoto2_port/libltdl/ltdl.c
gphoto2-2.2.0-3.el5: (source) libgphoto2-2.2.1.tar.bz2: libgphoto2-2.2.1/libltdl/ltdl.c
ImageMagick-6.2.8.0-4.el5_1.1: (source) ImageMagick-6.2.8-0.tar.bz2: ImageMagick-6.2.8/ltdl/ltdl.c
kdelibs-3.5.4-22.el5.centos: (source) kdelibs-3.5.4.tar.bz2: kdelibs-3.5.4/libltdl/ltdl.c
lam-7.1.2-14.el5: (source) lam-7.1.2-rh1.tar.bz2: lam-7.1.2-rh1/share/libltdl/ltdl.c
libtool-1.5.22-6.1: (source) libtool-1.5.22.tar.gz: libtool-1.5.22/libltdl/ltdl.c
openmpi-1.3.2-2.el5: (source) openmpi-1.3.2.tar.bz2: openmpi-1.3.2/opal/libltdl/ltdl.c
scim-1.4.4-41.el5: (source) scim-1.4.4-20060716.tar.gz: scim-1.4.4-20060716/src/ltdl.cpp
scim-chinese-standard-0.0.2-1.el5: (source) scim-chinese-standard-0.0.2.tar.gz: scim-chinese-standard-0.0.2/src/ltdl.c
unixODBC-2.2.11-7.1: (source) unixODBC-2.2.11.tar.gz: unixODBC-2.2.11/libltdl/ltdl.c
xmlsec1-1.2.9-8.1: (source) xmlsec1-1.2.9.tar.gz: xmlsec1-1.2.9/src/ltdl.c
xmlsec1-1.2.9-8.1: (source) xmlsec1-1.2.9.tar.gz: xmlsec1-1.2.9/src/xmlsec-ltdl.c

Comment 18 Peter O'Gorman 2009-11-18 02:11:55 UTC
For the second issue, lt_dlopen looking for .la files in the current working directory, it only does this if it has been given a path without a directory component e.g. "foo.la". If given an absolute path lt_dlopen will look only at that path.

Thanks for the handy list of packages in comment #10.

Comment 19 Peter O'Gorman 2009-11-18 02:15:36 UTC
Oh - it is likely that some of the packages that use an embedded libltdl use an older one, we posted a patch to the libtool list with a backport of the change to branch-1-5.
http://lists.gnu.org/archive/html/libtool/2009-11/msg00065.html

Of course, if the packages work with the system libltdl, so much the better.

Comment 23 Vincent Danen 2009-11-18 17:27:29 UTC
Upstream xmlsec1 has removed the internal copy as of Nov 7th, and due to it implementing crypto XML support, xmlsec1 should be patched to correct this as well.

Comment 25 Vincent Danen 2009-11-18 17:37:15 UTC
unixODBC 2.2.14 uses the system libltdl, so only versions prior to that would contain the vulnerable code.

Comment 32 Vincent Danen 2009-11-19 18:33:43 UTC
Created attachment 372311 [details]
test suite for libltdl

This test suite tests the behaviour of libltdl by using lt_dlopen() and lt_dlopenext() on a variety of filenames (thanks Tomas for the testing code).

Run before patching libtool on Fedora 11, and after, the git commits noted earlier do correct the issue and neither function looks at the $CWD for a .la file nor do they follow any specification in old_library if an .la file is loaded (which is only possible if it is in the path or a relative path is provided).

Comment 33 Vincent Danen 2009-11-19 18:34:53 UTC
Created attachment 372312 [details]
patch to fix the flaw in libtool 2.x

Comment 34 Vincent Danen 2009-11-19 18:40:18 UTC
For the embedded libltdl packages, we need to determine whether or not the package in question only uses the full path or if it always adds .so.  If either of these are true, then the package should not be affected by this flaw.  If .so is specified to either lt_dlopen() or lt_dlopenext(), it will never tried to load a .la file (but any extension other than .so will result in lt_dlopenext() looking for $file.la and then $file.so).  lt_dlopen() will not append a file extension when searching for $file.

Comment 35 Vincent Danen 2009-11-19 18:48:04 UTC
To clarify the above, it's ok if .so is appended to a module name (or appended if it doesn't exist), because neither function will load a .so in the $CWD (pass a .so to either function and it always looks in the standard locations, even if a .so exists in $CWD, it is never touched).

Comment 43 Vincent Danen 2009-11-30 18:45:33 UTC
Additional possible problematic packages (for Fedora): heartbeat, proftpd, prelude, sane, GraphicsMagick, libtunepimp, smalltalk, and redland (based on Mandriva's package list advisory: http://www.mandriva.com/en/security/advisories?name=MDVSA-2009:307 )

Comment 44 Vincent Danen 2009-11-30 18:51:40 UTC
pspell handles this appropriately:

  PspellString libname;
  libname  = LIBDIR "/libpspell_";
  libname += name;
  libname += ".la";
  lt_dlhandle h = lt_dlopen (libname.c_str());

where LIBDIR is defined at compile-time as ${libdir}; at any rate it definitely uses the system libltdl.

Comment 51 Fedora Update System 2009-12-02 11:50:27 UTC
libtool-2.2.6-11.fc11.2 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/libtool-2.2.6-11.fc11.2

Comment 52 Fedora Update System 2009-12-02 11:50:41 UTC
libtool-2.2.6-17.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/libtool-2.2.6-17.fc12

Comment 53 Fedora Update System 2009-12-02 11:50:55 UTC
libtool-1.5.26-4.fc10.1 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/libtool-1.5.26-4.fc10.1

Comment 54 Jan Lieskovsky 2009-12-02 16:11:54 UTC
Patch user for GraphicsMagick-1.3.7:

  http://bugs.gentoo.org/attachment.cgi?id=211756&action=view

Comment 55 Jan Lieskovsky 2009-12-02 16:14:25 UTC
Created attachment 375475 [details]
Local copy of Gentoo patch for CVE-2009-3736 for GraphicsMagick-1.3.7

Comment 56 Jan Lieskovsky 2009-12-02 16:27:26 UTC
Andreas, Rex, 

  could you schedule Fedora GraphicsMagick update with above patch?

Thanks, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team

Comment 66 Fedora Update System 2009-12-03 12:34:57 UTC
libtool-2.2.6-11.fc11.3 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/libtool-2.2.6-11.fc11.3

Comment 67 Fedora Update System 2009-12-04 20:55:24 UTC
gcc-4.4.2-14.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/gcc-4.4.2-14.fc12

Comment 68 errata-xmlrpc 2009-12-08 19:04:38 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 3
  Red Hat Enterprise Linux 4
  Red Hat Enterprise Linux 5

Via RHSA-2009:1646 https://rhn.redhat.com/errata/RHSA-2009-1646.html

Comment 88 Vincent Danen 2009-12-17 20:03:02 UTC
While unixODBC contains a vulnerable embedded libltdl, the impact of this issue on unixODBC is low to none.

unixODBC calls lt_dlopen(), not ld_dlopentxt() and as a result a user would have to use a driver name with .la (explicitly) in order to exploit this.  All documentation for unixODBC indicates to use the full path to a .so file, so this scenario is extremely unlikely.  We do not ship .la files in unixODBC so there is no reason for a user to configure unixODBC with .la files rather than the provided (and documented) usage of .so files.

Likewise, unixODBC does not search for modules in untrusted directories, and will only look in the current directory if the specified driver is a .la file.

As a result, we do not see this issue as posing any kind of threat with regards to unixODBC and will not be issuing updated packages.

Comment 89 Fedora Update System 2009-12-22 04:39:52 UTC
libtool-2.2.6-11.fc11.3 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 90 Fedora Update System 2009-12-29 18:58:16 UTC
libtool-2.2.6-17.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 91 Fedora Update System 2009-12-29 18:58:52 UTC
gcc-4.4.2-20.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 92 errata-xmlrpc 2010-01-13 17:35:11 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 3
  Red Hat Enterprise Linux 4
  Red Hat Enterprise Linux 5

Via RHSA-2010:0039 https://rhn.redhat.com/errata/RHSA-2010-0039.html

Comment 93 Vincent Danen 2010-02-10 22:43:34 UTC
Is anyone here against filing a bug to get as many of these embedded libltdl packages using the system libltdl as possible?  I'm going through everything in Fedora right now that uses libltdl internally (weeded out those already using the system libltdl) and while most look ok to not warrant an immediate fix, I'd feel much more comfortable going forward if we could make as many of these as we can use the system library rather than an embedded copy.

Once I'm finished checking the list I'll note it here and indicate which ones should be fixed in Fedora right away (or at least that need a more expert eye to look at).

Comment 94 Vincent Danen 2010-02-11 04:59:30 UTC
Ok, here are the results of my checking on the Fedora packages that contain embedded libltdl and have either not been fixed yet (based on a notification of a package release on this bug), or contain embedded libltdl but use the system libltdl and are therefore not affected anymore.

Fedora 11

gcc-4.4.0-4: (source) gcc-4.4.0-20090506.tar.bz2: gcc-4.4.0-20090506/libjava/libltdl/ltdl.c
  - this was updated for Fedora 12, but not Fedora 11

Fedora 11 and 12:

bochs-2.3.8-0.8.git04387139e3b.fc12: (source) bochs-2.3.8.tar.gz: bochs-2.3.8/ltdl.c
  - uses lt_dlopen() in plugin.cc but provides a full path (PLUGIN_PATH=@libdir@/bochs/plugins/
callweaver-1.2.1-2.fc12: (source) callweaver-1.2.1.tar.bz2: callweaver-1.2.1/libltdl/ltdl.c
  - uses lt_dlopen() in corelib/loader.c but provides a full path
    (cw_config_CW_MODULE_DIR=cwmoddir=${cwlibdir}/modules)
clamav-0.95.2-5.fc12: (source) clamav-0.95.2-norar.tar.bz2: clamav-0.95.2/libltdl/ltdl.c
  - uses lt_dlopen() in libclamav/others.c; will search current directory
    (searchpath=""), but also appends pre-defined suffixes to the module
    name when searching (LT_MODULE_EXT(,LIBCLAMAV_FULLVER,LIBCLAMAV_MAJORVER),.LT_LIBEXT);
    LT_LIBEXT is defined as 'a' in ltdl.c, but clamav-config.h undef's it
collectd-4.6.5-1.fc12: (source) collectd-4.6.5.tar.bz2: collectd-4.6.5/libltdl/ltdl.c
  - uses lt_dlopen() in src/plugin.c in plugin_load_file(), called by
    plugin_load() which searches a given directory for modules and attempts
    to load them, directory provided by plugin_get_dir() which returns the
    compiled in default of $pkglibdir or the specified value of PluginDir
    in the config (if set), but since it's looking for full names in a
    directory, they will contain extensions so no ext-based searching; we
    also set PluginDir to /usr/lib/collectd in /etc/collectd.conf by
    default
cpl-4.2.0-4.fc12: (source) cpl-4.2.0.tar.gz: cpl-4.2.0/libltdl/ltdl.c
  - uses lt_dlopen() in cpljava/cpl_gasgano.c; first invocation calls
    lt_dlsetseachpath() first; second uses a hardcoded .so; not sure where
    the path comes from in the first call (path is passed to the function,
    but can't see where that function is used -- from apps that call that
    function externally perhaps?)
esorex-3.6.12-4.fc12: (source) esorex-3.6.12.tar.gz: esorex-3.6.12/libltdl/ltdl.c
  - uses lt_dlopen in src/er_pluginlist.c in numerous functions; plugin_valid_file() looks ok (passed a
    full file path/name), but unsure of the rest
gambas-1.0.19-11.fc12: (source) gambas-1.0.19.tar.bz2: gambas-1.0.19/libltdl/ltdl.c
  - uses lt_dlopenext() in src/exec/gbx_library.c and src/comp/gbi.c;
    unsure if this one passes full paths/filenames or not; probably
    requires fixing
ggobi-2.1.7-3.fc12: (source) ggobi-2.1.7.tar.bz2: ggobi-2.1.7/libltdl/ltdl.c
  - uses lt_dlopen() in src/plugin.c, filename provided by
    ggobi_find_data_file(), which looks in $GOBI_HOME and the current
    directory; requires fixing
gnash-0.9.0-0.6.20090809bzr11401.fc12: (source) gnash-0.9.0.20090809bzr11401.tar.gz: gnash-0.9.0/gnash-trunk/libltdl/ltdl.c
  - uses lt_dlopenext() in libbase/{sharedlib.cpp,extension.cpp} and
    cygnal/cgi-bin/oflaDemo/oflaDemo.cpp; probably suspect but I don't do
    C++ so can't verify
gnu-smalltalk-3.1-7.fc12: (source) smalltalk-3.1.tar.gz: smalltalk-3.1/lib-src/ltdl.c
  - uses lt_dlopenext() in libgst/cint.c and snprintfv/snprintfv/dl-yes.c;
    for cint.c not sure where the filename comes from (don't see a call to
    the dld_open() function anywhere, unless it is the dldLink
    definition that is uses in kernel/DLD.st -- at that point I have no
    idea what is going on), for dl-yes.c it will attempt to load every
    module in LTDL_LIBRARY_PATH environment variable (from
    snv_load_all_modules()); possibly requires fixing
hamlib-1.2.9-1.fc12: (source) hamlib-1.2.9.tar.gz: hamlib-1.2.9/libltdl/ltdl.c
  - uses lt_dlopenext() and lt_dlopen() in src/rot_reg.c and
    src/register.c; modules are automatically prefixed with 'hamlib-', and
    looks like ROT_BACKEND_LIST is a hard-coded list of modules to load,
    but no path specification that I can see
libannodex-0.7.3-12.fc12: (source) libannodex-0.7.3.tar.gz: libannodex-0.7.3/libltdl/ltdl.c
  - uses lt_dlopen() in src/libannodex/fix_dl.c, used in dlopen_F(); looks
    like it is passed a full pathname (set in
    anx_register_all_media_importers_dir() from src/libannodex/anx_import.c
libnetdude-0.11-3.fc12: (source) libnetdude-0.11.tar.gz: libnetdude-0.11/libltdl/ltdl.c
  - uses lt_dlopenext() in src/libnd_{plugin,protocol_plugin}.c; not sure
    about this one, looks like it's iterating over a list of plugins but
    not sure where the list is coming from so can't determine if they're
    full paths or not; possibly requires fixing
libprelude-0.9.24.1-1.fc12: (source) libprelude-0.9.24.1.tar.gz: libprelude-0.9.24.1/libltdl/ltdl.c
  - uses lt_dlopenext() in src/prelude-plugins.c, which is ultimately
    called through prelude_plugin_load_from_dir() which takes a directory
    name as an argument so presumably it will be passed a full filename,
    but this maybe depends on what is calling that function (an external
    app using libprelude by the looks of things); possibly requires fixing
    unless we can determine that a full path is always being passed
mingw32-libltdl-1.5.26-14.fc12: (source) libtool-1.5.26.tar.gz: libtool-1.5.26/libltdl/ltdl.c
  - absolutely no idea on this one; looks like windows binaries for
    cross-compiling, but I don't know if this issue affects windows dll
    loading or not
naim-0.11.8.3.1-8.fc12: (source) naim-0.11.8.3.1.tar.bz2: naim-0.11.8.3.1/libltdl/ltdl.c
  - uses lt_dlopen() in src/conio.c, but all calls are either NULL or a
    .dll filename (for cygwin?), one uses lt_dlopenext() on args[0]
    (self?); probably ok but definitely odd
proftpd-1.3.2b-1.fc12: (source) proftpd-1.3.2b.tar.bz2: proftpd-1.3.2b/lib/libltdl/ltdl.c
  - uses lt_dlopen() and lt_dlopenext() in modules/mod_dso.c; lt_dlopen()
    is safe (loads self), lt_dlopenext() opens a module with a full
    pathname ($prefix/libexec/<module>) or from LoadFile in the config
    (must be a full file and path); should be ok
q-7.11-6.fc12: (source) q-7.11.tar.gz: q-7.11/libltdl/ltdl.c
  - uses lt_dlopen() and lt_dlopenext() in src/sys.c and lt_dlopenext() in
    src/q.c; looks like in sys.c it's redefining both functions, in q.c it
    looks a little fishy to me but I can't be sure; possibly requires
    fixing
sdcc-2.9.0-4.fc12: (source) sdcc-src-2.9.0.tar.bz2: sdcc/sim/ucsim/libltdl/ltdl.c
  - not entirely sure where there is an embedded libltdl here; lt_dlopen*()
    is not used at all
ski-1.3.2-8.fc12: (source) ski-1.3.2.tar.gz: ski-1.3.2/src/ltdl.c
  - uses lt_dlopen() in src/sim.c; tries to open the value of the
    SKIHOOK_PATH environment variable; I suppose this must be pointing to a
    file of some sort (not noted elsewhere in the code); only a problem if
    the user sets this env var to a relative path; should be fine
squid-3.1.0.14-1.fc12: (source) squid-3.1.0.14.tar.bz2: squid-3.1.0.14/lib/libLtdl/ltdl.c
  - uses lt_dlopen() in src/LoadableModule.cc; I have no idea about this
    one; probably should be checked by the maintainer
vrq-1.0.62-1.fc12: (source) vrq-1.0.62.tar.gz: vrq-1.0.62/libltdl/ltdl.c
  - uses lt_dlopen() in plugin/sim/pliext.cc and src/main.cc; looks like in
    all cases it uses a full path and filename prefixed by pluginPath;
    should be ok
whatsup-1.9-2.fc12: (source) whatsup-1.9.tar.gz: whatsup-1.9/src/libcommon/ltdl.c
  - uses lt_dlopen() in src/whatsup/whatsup.c,
    src/libnodeupdown/nodeupdown_module.c, and src/pingd/pingd_config.c; in
    whatsup.c loads a full path in WHATSUP_MODULE_DIR; in
    nodeupdown_module.c loads a full path in NODEUPDOWN_MODULE_DIR; and
    PINGD_MODULE_DIR in pingd_config.c; should be ok

So, for the above, the following packages need to be fixed or updated by their respective maintainers:

- gcc (in Fedora 11)
- esorex
- gambas
- ggobi
- gnash
- gnu-smalltalk
- hamlib
- libnetdude
- libprelude
- mingw32-libltdtl
- q
- squid

Comment 107 Fedora Update System 2010-02-11 22:51:01 UTC
mingw32-libltdl-1.5.26-20.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/mingw32-libltdl-1.5.26-20.fc12

Comment 108 Fedora Update System 2010-02-11 22:51:19 UTC
mingw32-libltdl-1.5.26-17.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/mingw32-libltdl-1.5.26-17.fc11

Comment 109 Fedora Update System 2010-02-12 02:57:44 UTC
gnash-0.8.6-13.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/gnash-0.8.6-13.fc12

Comment 110 Fedora Update System 2010-02-12 02:58:11 UTC
gnash-0.8.6-13.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/gnash-0.8.6-13.fc11

Comment 111 Fedora Update System 2010-02-13 00:36:28 UTC
gnash-0.8.6-13.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 112 Fedora Update System 2010-02-13 00:39:06 UTC
gnash-0.8.6-13.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 113 Fedora Update System 2010-02-18 18:37:00 UTC
esorex-3.7.2-6.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/esorex-3.7.2-6.fc13

Comment 114 Fedora Update System 2010-02-18 18:39:27 UTC
esorex-3.7.2-5.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/esorex-3.7.2-5.fc12

Comment 115 Fedora Update System 2010-02-18 18:41:03 UTC
esorex-3.7.2-3.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/esorex-3.7.2-3.fc11

Comment 116 Fedora Update System 2010-02-18 18:41:55 UTC
esorex-3.7.2-5.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/esorex-3.7.2-5.fc12

Comment 117 Fedora Update System 2010-02-18 18:42:27 UTC
esorex-3.7.2-3.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/esorex-3.7.2-3.fc11

Comment 118 Fedora Update System 2010-02-18 18:44:06 UTC
esorex-3.7.2-6.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/esorex-3.7.2-6.fc13

Comment 119 Fedora Update System 2010-02-18 18:44:21 UTC
esorex-3.7.2-5.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/esorex-3.7.2-5.fc12

Comment 120 Fedora Update System 2010-02-18 18:44:35 UTC
esorex-3.7.2-3.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/esorex-3.7.2-3.fc11

Comment 121 Fedora Update System 2010-02-26 03:38:03 UTC
mingw32-libltdl-1.5.26-20.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 122 Fedora Update System 2010-02-26 03:40:11 UTC
mingw32-libltdl-1.5.26-17.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 123 Fedora Update System 2010-03-10 06:54:34 UTC
esorex-3.7.2-6.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 124 Fedora Update System 2010-03-11 19:01:42 UTC
hamlib-1.2.10-2.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/hamlib-1.2.10-2.fc12

Comment 125 Fedora Update System 2010-03-11 19:05:13 UTC
hamlib-1.2.8-4.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/hamlib-1.2.8-4.fc11

Comment 126 Fedora Update System 2010-03-20 03:29:08 UTC
esorex-3.7.2-5.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 127 Fedora Update System 2010-03-20 03:51:20 UTC
esorex-3.7.2-3.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 128 Fedora Update System 2010-04-03 04:46:54 UTC
hamlib-1.2.10-2.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 129 Fedora Update System 2010-04-03 04:48:19 UTC
hamlib-1.2.8-4.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 131 Josh Bressers 2011-07-25 16:49:03 UTC
Statement:

(none)

Comment 132 Vincent Danen 2012-08-10 19:16:05 UTC
This has been fixed in upstream GraphicsMagick:

2011-10-21  Bob Friesenhahn  <bfriesen.tx.us>

* libtool: Updated to libtool 2.4.2.


Note You need to log in before you can comment on or make changes to this bug.