Hi, (Cc'ing debian-release for comments about an s-p-u upload [see below for details] and the collectd mailing-list for possible further comments about this.)
Thanks a lot for reporting this! On Sun, Dec 06, 2009 at 11:52:20PM -0500, Michael Gilbert wrote: > The following CVE (Common Vulnerabilities & Exposures) id was > published for libtool. I have determined that this package embeds a > vulnerable copy of the libtool source code. However, since this is a > mass bug filing (due to so many packages embedding libtool), I have not > had time to determine whether the vulnerable code is actually present > in any of the binary packages. Please determine whether this is the > case. If the package is not affected, please feel free to close the bug > with a message containing the details of what you did to check. > > CVE-2009-3736[0]: > | ltdl.c in libltdl in GNU Libtool 1.5.x, and 2.2.6 before 2.2.6b, > | attempts to open a .la file in the current working directory, which > | allows local users to gain privileges via a Trojan horse file. collectd uses libltdl to load plugins. This is done by lt_dlopen()'ing shared objects specified by a full path name. When looking at the libtool release notes and the patch [1], the CVE only affects code which loads .la files. Basically, this is not the case for collectd. However, when loading a plugin, collectd searches a configurable directory for a file called "<plugin_name>.so". This is done using strncasecmp(), specifying the length of "<plugin_name>.so" as the number of characters to consider. So, in theory, a file named "<plugin_name>.so <something>.la" could be loaded instead. For this to be exploitable by a user, that user would need write privileges for the plugin directory, in which case she could "inject" arbitrary plugins anyway. Anyway, I guess, it might be possible to construct some obscure situation in which a somewhat valid setup might, under certain circumstances, be affected by this ;-) In unstable, I'm going to fix this twofold: a) upstream has updated to libtool 2 by now, thus making it possible to easily use libltdl available on the host system (instead of the shipped copy) and b) by using strcasecmp() instead of strncasecmp(), thus making it impossible to load .la files (libltdl uses the filename extension to determine that). This way, the problem no longer exists, even if a vulnerable libltdl is used on some system. All plugin files in Debian are called "<plugin_name>.so", so this won't cause any problems. However, I'm not sure if this warrants a s-p-u upload. OTOH, imho, it does not really hurt either. In that case, I'd apply the upstream patch [1] to the embedded libltdl copy and patch collectd as mentioned above (b). Would that be fine for the release team? Cheers, Sebastian > For further information see: > > [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3736 > http://security-tracker.debian.org/tracker/CVE-2009-3736 [1] http://lists.gnu.org/archive/html/libtool/2009-11/txtMKTxOo47fF.txt -- Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin
signature.asc
Description: Digital signature
