[PATCH] Backport two ltdl fixes to fix CVE-2009-3736

[Ralf Wildenhues]

Hello Jakub,

* Jakub Jelinek wrote on Thu, Dec 03, 2009 at 10:11:50AM CET:
> libgcj System.loadLibrary which uses lt_dlopen{,ext} under the hood
> tries to open even files in the current directory.  When running
> a Java program from an untrusted directory (such as /tmp), someone might
> put there a rogue *.la or *.so file and let libgcj dlopen it instead of
> the library it was supposed to load.  Additionally, while e.g. libtool.m4
> in gcc 4.4/4.5 is correct, acinclude.m4 in libjava/libltdl hasn't been
> regenerated and so the hardcoded search path to libraries could include
> stuff like ...:hwcap:0:nosegneg:... and search hwcap/, 0/ and nosegneg/
> subdirs of the current directory for *.la files and *.so libraries.
> 
> Fixed thusly, bootstrapped/regtested on {x86_64,i686,powerpc{,64}}-linux.
> Ok for 4.4/4.3?  The trunk I'll leave for Ralf's 2.2.6b backport instead.

I think you should apply this patch to trunk as well.  libjava/libltdl
does not pick up the changes from the toplevel Libtool files.  I wonder
whether that is a bug in itself; OTOH, I remember there have been
problems in the past with trying to get old libltdl to work with newer
Libtool macro files.

Thanks,
Ralf

> 2009-12-03  Jakub Jelinek  <jakub@redhat.com>
> 
> 	* acinclude.m4: Regenerated to pick:
> 	2007-06-22 Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
> 	* libtool.m4 (AC_LIBTOOL_SYS_DYNAMIC_LINKER) [linux]:
> 	Ignore lines in ld.so.conf starting with 'hwcap '.
> 
> 	* configure: Regenerated.
> 
> 	2009-11-24  Peter O'Gorman  <peter@pogma.com>
> 
> 	Backport of libltdl changes from the 2.26b release.
> 	* ltdl.c: Backport changes.