From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030709 Description of problem: I removed all the ssh and ssl rpms that get installed by Fedora as these versions are out of date and have known security holes. I then went to build and install the latest version of ssl. This completed successfully and it installed the the following shared libraries: libcrypto.so.0.9.7 and libssl.so.0.9.7 in /usr/local/ssl/lib. I then created the following symbolic links to these two libraries within the same directory: libcrypto.so.4 and libssl.so.4 I then added the path /usr/local/ssl/lib to /etc/ld.so.conf and ran ldconfig so that it included all the new libraries in ld.so.cache I then ran the /usr/bin/host command in order to test that the ldconfig command had worked successfully, because /usr/bin/host needs the shared library libcrypto.so.4 in order to run. The host command failed with the following error: "host: error while loading shared libraries: libcrypto.so.4: cannot open shared object file: No such file or directory" The above proceedure has worked perfectly for me on RH 7.1, 7.2, 7.3, 8.0, 9.0 Out of curiosity I copied the /sbin/ldconfig excecutable from a RH 9.0 PC to my fedora core test3 PC, and ran it. The /usr/bin/host command then ran perfectly. It is important to be running the latest versions of ssl and ssh for obvious reasons, and you can't always wait for rpms to be produced. So building ssl and ssh from source code is essential. Could someone please take a look at the ldconfig executable that comes with Fedroa core Test3 Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Please read my description, the steps to reproduce are clearly spelled out. Actual Results: see description Expected Results: see description Additional info:
I'm afraid the basis of your beliefs are incorrect. The openssl/openssh rpm's available from the updates channel (or as installed if no updates are available) have been patched against all known security errata. Oftimes redhat will backport a fix to an earlier openssl/openssh core rather than increment the version, obviously this has convinced you that these versions were vulnerable when in fact they are not. The source RPM's and changelog comments (rpm -q --changelog) include the details of the patches applied to these versions.
I second Tom's observation. I too have run into this bug and exactly as he described. I even went as far as moving the directory around, etc. No change. I did get a proper result when creating symbolic links in /usr/lib for libssl.so.4. I also could make it work when exporting LD_LIBRARY_PATH with /usr/local/ssl/lib. The odd thing is that my DB4 libs under /usr/local/db4 where picked up just fine. The only difference was the libdb-4.xxx.so was not a symbolic link, while libssl.so.4 was... maybe a clue to the problem?
Please attach ldconfig -p output, ls -l /usr/local/ssl/lib output and for i in /usr/local/ssl/lib/lib*.so*; do echo $i; readelf -d $i; done output. The #1 comment is correct, to my knowledge there are no known security holes in openss{h,l} packages included in the FC1 updates rpms (for openssl) or FC1 rpms (in openssh case).
Looking at openssl src.rpm, my guess is that you need openssl-0.9.7a-soversion.patch patch and you'll be ok then. ldconfig uses primarily DT_SONAME values.
Removing security severity; This is not a security issue, it's a library problem.
No reply in 4 months, closing. This does not look like any problem in glibc, but instead as in openssl. If you ignore patches which are in the RH versions then don't wonder if something breaks.