[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#559802: CVE-2009-3736 local privilege escalation


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

    So this will happen if the static version of the plugin was built.


Reply to: