[collectd] Bug#559801: CVE-2009-3736 local privilege escalation

[Sebastian Harl]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20091225/4e4a34e7/attachment.pgp