Bug 537941 (CVE-2009-3736)
Summary: | CVE-2009-3736 libtool: libltdl may load and execute code from a library in the current directory | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Other] Security Response | Reporter: | Vincent Danen <vdanen> | ||||||||
Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> | ||||||||
Status: | CLOSED ERRATA | QA Contact: | |||||||||
Severity: | medium | Docs Contact: | |||||||||
Priority: | medium | ||||||||||
Version: | unspecified | CC: | andreas, aph, dledford, hhorak, jakub, jgrulich, jlieskov, jreznik, karsten, kreilly, ldimaggi, mehmetgelisin, mjc, peter, petersen, qe-baseos-apps, rdieter, security-response-team, than | ||||||||
Target Milestone: | --- | Keywords: | Security | ||||||||
Target Release: | --- | ||||||||||
Hardware: | All | ||||||||||
OS: | Linux | ||||||||||
URL: | http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3736 | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | libtool 2.2.6b | Doc Type: | Bug Fix | ||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2016-03-31 10:10:07 UTC | Type: | --- | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Bug 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 | ||||||||||
Bug Blocks: | |||||||||||
Attachments: |
|
Description
Vincent Danen
2009-11-16 20:59:20 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. 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 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. 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. 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. unixODBC 2.2.14 uses the system libltdl, so only versions prior to that would contain the vulnerable code. 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).
Created attachment 372312 [details]
patch to fix the flaw in libtool 2.x
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. 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). 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 ) 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. 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 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 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 Patch user for GraphicsMagick-1.3.7: http://bugs.gentoo.org/attachment.cgi?id=211756&action=view Created attachment 375475 [details] Local copy of Gentoo patch for CVE-2009-3736 for GraphicsMagick-1.3.7 Andreas, Rex, could you schedule Fedora GraphicsMagick update with above patch? Thanks, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team 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 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 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 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. 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. 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. 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. 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 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). 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 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 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 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 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 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. 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. 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 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 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 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 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 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 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 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 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. 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. 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. 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 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 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. 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. 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. 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. Statement: (none) This has been fixed in upstream GraphicsMagick: 2011-10-21 Bob Friesenhahn <bfriesen.tx.us> * libtool: Updated to libtool 2.4.2. |