Insecure creation of shared libraries in openssl-0.9.8b.
The following problem exists for the AIX platform (and maybe others).
CC=xlc ./config --prefix=/usr/local shared
make CC=xlc
make install
creates libcrypto.so, libssl.so and engines/*.so with relative paths
(. and .. respectively) in the loader section of the libraries.
dump -H libssl.so for instance shows the following:
libssl.so:
***Loader Section***
Loader Header Information
VERSION# #SYMtableENT #RELOCent LENidSTR
0x00000001 0x00000299 0x00000bf4 0x0000003c
#IMPfilID OFFidSTR LENstrTBL OFFstrTBL
0x00000003 0x0000cde8 0x00003197 0x0000ce24
***Import File Strings***
INDEX PATH BASE MEMBER
0 .:/usr/vac/lib:/usr/lib:/lib
1 libcrypto.so
2 libc.a shr.o
Having relative paths in the library search path is generaly regarded as
a security issue.
The problem can be circumvented by using the following commands:
CC=xlc ./config --prefix=/usr/local shared
make CC=xlc EX_LIBS='-blibpath:$(INSTALLTOP)/lib:/usr/lib:/lib'
make install
As it is now the generated applications (i.e openssl command) are linked
to the static libraries (lib*.a) so "make test" still works but does not
test the shared libraries. It is possible to trick "make" into linking
to the shared libraries, but then "make test" is no longer valid because
it either fails (if the openssl libraries have never been installed
before) or use the libraries of the previously installed version.
A proper solution would require "make" to link without -blibpath:
and "make install", instead of copying, to link using the proper
-blibpath: option.
Paul Tedaldi
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
