openssh unix dev - May 2002 - mismatch against version of openssl, letter version brokeness

What risk exists in changing the check for the matching version of
openssl so that the final letter part of the version (e.g. 0.9.6c
vs. 0.9.6d) is ignored?  Are there any security vulnerabilities in
such a thing?  What if ssh(d) is linked against an older _letter_
version such as 0.9.6c and now finds the library is 0.9.6d?  Is
there a security risk in that?  Surely a major API change would not
happen between version c and version d, would it?

My concern here is that openssl's versioning scheme is broken, and
depending on it causes problems.  For example, I cannot concurrently
have separate executables with some linked to 0.9.6c and some linked
to 0.9.6d and expect them to get the correct library, because the
library itself cannot have concurrent versions installed (hence why
I say it is broken).

-- 
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/     |
-----------------------------------------------------------------

Circa 2002-May-25 15:13:43 -0500 dixit Phil Howard:

: What risk exists in changing the check for the matching version of
: openssl so that the final letter part of the version (e.g. 0.9.6c
: vs. 0.9.6d) is ignored?  Are there any security vulnerabilities in
: such a thing?  What if ssh(d) is linked against an older _letter_
: version such as 0.9.6c and now finds the library is 0.9.6d?  Is
: there a security risk in that?  Surely a major API change would not
: happen between version c and version d, would it?
: 
: My concern here is that openssl's versioning scheme is broken, and
: depending on it causes problems.  For example, I cannot concurrently
: have separate executables with some linked to 0.9.6c and some linked
: to 0.9.6d and expect them to get the correct library, because the
: library itself cannot have concurrent versions installed (hence why
: I say it is broken).

According to the INSTALL file included with OpenSSL-0.9.6d:

   Shared library is currently an experimental feature.  The only
   reason to have them would be to conserve memory on systems where
   several program are using OpenSSL.  Binary backward compatibility
   can't be guaranteed before OpenSSL version 1.0.
      
That explains why it's necessary for OpenSSH to explicitly depend on a
particular version of OpenSSL (i.e., backwards compatibility can't be
guaranteed with v0.9.x).

That said, what i usually do is apply the attached patch (for Linux on
x86 hardware) to change the SONAME of the libraries from, for example,
'libcrypto.so.0.9.6' to 'libcrypto-0.9.6d.so.0'.  This does the
following:

  (1) Allows easy coexistence between different version of the OpenSSL
      libraries.
      
  (2) Makes explicit what the INSTALL text implies, i.e. that
      libcrypto-0.9.6c.so.0 and libcrypto-0.9.6d.so.0 are not
      guaranteed to be ABI compatible.

YMMV.

-- 
jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491)
-------------- next part --------------
--- ./Configure.orig-shlib	Fri May 10 15:05:03 2002
+++ ./Configure	Fri May 10 15:12:22 2002
@@ -334,7 +334,7 @@
 
 # The intel boxes :-), It would be worth seeing if bsdi-gcc can use the
 # bn86-elf.o file file since it is hand tweaked assembler.
-"linux-elf",	"gcc:\$(OPTFLAGS) -DL_ENDIAN
-DTERMIO::-D_REENTRANT:-ldl:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
+"linux-elf",	"gcc:\$(OPTFLAGS) -DL_ENDIAN
-DTERMIO::-D_REENTRANT:-ldl:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-fPIC::-\$(VERSION).so.0.0.0",
 "debug-linux-elf","gcc:-DBN_DEBUG -DREF_CHECK -DCONF_DEBUG
-DBN_CTX_DEBUG -DCRYPTO_MDEBUG -DL_ENDIAN -DTERMIO -g -m486
-Wall::-D_REENTRANT:-lefence -ldl:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-fPIC:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
 "debug-linux-elf-noefence","gcc:-DBN_DEBUG -DREF_CHECK
-DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -DL_ENDIAN -DTERMIO -g -m486
-Wall::-D_REENTRANT:-ldl:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_elf_asm}:dlfcn",
 "linux-aout",	"gcc:-DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer
-m486 -Wall::(unknown)::BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_out_asm}",
--- ./Makefile.org.orig-shlib	Fri May 10 15:07:00 2002
+++ ./Makefile.org	Fri May 10 15:11:35 2002
@@ -261,8 +261,8 @@
 do_gnu-shared:
 	libs='-L. ${SHLIBDEPS}'; for i in ${SHLIBDIRS}; do \
 	( set -x; ${CC} ${SHARED_LDFLAGS} \
-		-shared -o lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \
-		-Wl,-soname=lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \
+		-shared -o lib$$i-${VERSION}.so.0.0.0 \
+		-Wl,-soname=lib$$i-${VERSION}.so.0 \
 		-Wl,-Bsymbolic \
 		-Wl,--whole-archive lib$$i.a \
 		-Wl,--no-whole-archive $$libs ${EX_LIBS} -lc ) || exit 1; \
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 262 bytes
Desc: not available
Url :
http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020525/87f485c6/attachment.bin

On Sat, May 25, 2002 at 03:13:43PM -0500, Phil Howard
wrote:
> What risk exists in changing the check for the matching version of
> openssl so that the final letter part of the version (e.g. 0.9.6c
> vs. 0.9.6d) is ignored?  Are there any security vulnerabilities in
> such a thing?
the API is not stable between the releases.