Hi!
On Tue, 2009-12-08 at 10:23:41 -0500, Michael Gilbert wrote:
> > 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.
>
> So, as i interpret the issue, the difference here is that libtool will
> load any and all .la and .a file available on the LD_LOAD_LIBRARY path;
> whereas python will load modules in the current directory only if they
> are specifically called from the script.
I think you mean LD_LIBRARY_PATH? And then I don't think that's a
problem, if you add ‘.’ to LD_LIBRARY_PATH then you get to keep the
pieces, in the same way if you add it to PATH.
> I have just recently realized that LD_LOAD_LIBRARY has a relatively
> safe default that does not include the current working directory.
> Given this fact, I believe that the impact is rather limited (only
> users that have modified that LD_LOAD_LIBRARY path are affected; and
> i'm sure there are those who have done this, but it is a minor subset
> of all debian users).
If you are talking about LD_LIBRARY_PATH, then the default is for it
to be empty.
> Hence, I think that for any package embedding libtool, updates should
> be pushed in stable-proposed-updates, rather than DSAs. As for libtool
> itself, it may still make sense to issue a DSA.
>
> If there is concurrence on this assessment, I will send a message along
> these lines to all of the bugs that I submitted.
The following are the conditions needed to trigger either of the
problematic cases, AFAIUI.
Both problems only happen iff:
* The caller requests to load a filename with a ‘.la’ extension
(explicitly via lt_dlopen or implicitly via lt_dlopenext).
* The filename does not have a directory component.
For the ‘.la’ problem:
* It will try to load the filename from the current directory iff
the search in all the other paths didn't succeed. Which includes
the paths from the dependency_libs field from the ‘.la’ file,
LTDL_LIBRARY_PATH, LD_LIBRARY_PATH, and the system default paths
from libltdl.
So this will mostly only happen when the plugin is not installed,
but the application requests it.
For the ‘.a’ problem:
* If the ‘.la’ file contains a non-empty “old_library” variable,
then it will try to load the static library name from the current
directory.
So this will happen if the static version of the plugin was built.
regards,
guillem