The nessus-bin ebuild specify a dependency for dev-libs/openssl, but since it's a binary pakage it specifically require <dev-libs/openssl-0.9.8 (linked against openssl-0.9.7) It should either handle properly the dependency and downgrade openssl (which I did) or use a binary version linked against openssl-0.9.8 if it exists (and force <=dev-libs/openssl-0.9.8 or course). Reproducible: Always Steps to Reproduce: 1. Install a brand new system (Mine is built around the hardened/2.6 i686 Stage3/profile) 2. Emerge net-analyzer/nessus-bin 3. Run nessusd Actual Results: Unhappy user (nessusd: error while loading shared libraries: libssl.so.0.9.7: cannot open shared object file: No such file or directory) Expected Results: Happy user Temporary fix: # emerge '<dev-libs/openssl-0.9.8' # revdep-rebuild
I just noticed that the "greater than or equal" sign is wrong in the 2nd paragraph. It should be: "[...] or use a binary version linked against openssl-0.9.8 if it exists (and force >=dev-libs/openssl-0.9.8 or course)."
News on this. After I noticed people using fedora were using symlinks to link to redhat's lib{crypto,ssl}.so.6 (which is OpenSSL 0.9.8) so I tried symlinking to 0.9.8 and it works! After upgrading to 0.9.8, revdep-rebuild and removing old 0.9.7 libs: ln -s /usr/lib/libssl.so.0.9.8 /usr/lib/libssl.so.0.9.7 ln -s /usr/lib/libcrypto.so.0.9.8 /usr/lib/libcrypto.so.0.9.7 Nessus daemon and command-line client runs and ssl communication works between them. Maybe this could at least be added as a comment after emerging, of even creating the symlink when installing...
Please try to reemerge openssl (I have dev-libs/openssl-0.9.8g). It should install different binaries and not the symlinks of these libraries: ls -al /usr/lib/libssl.so* lrwxrwxrwx 1 root root 15 2007-11-09 09:31 /usr/lib/libssl.so -> libssl.so.0.9.8 -r-xr-xr-x 1 root root 164464 2007-11-09 09:31 /usr/lib/libssl.so.0.9.7 -r-xr-xr-x 1 root root 283236 2007-11-09 09:31 /usr/lib/libssl.so.0.9.8 equery f openssl | grep libssl.so /usr/lib/libssl.so /usr/lib/libssl.so.0.9.7 /usr/lib/libssl.so.0.9.8
The libssl.so.0.9.7 file is left behind after upgrades from 0.9.7 to 0.9.8 and is vulnerable to any security bug of that 0.9.7 release. If you remove libssl.so.0.9.7 it won't re-appear when you emerge openssl-0.9.8. You're also getting notified by emerge when it leaves old libs behind: from your ebuild: pkg_preinst() { preserve_old_lib /usr/$(get_libdir)/lib{crypto,ssl}.so.0.9.{6,7} } pkg_postinst() { preserve_old_lib_notify /usr/$(get_libdir)/lib{crypto,ssl}.so.0.9.{6,7} [...]
(In reply to comment #4) > The libssl.so.0.9.7 file is left behind after upgrades from 0.9.7 to 0.9.8 and > is vulnerable to any security bug of that 0.9.7 release. you are right! I had vulnerable binaries in my system :( Ok, I've uploaded an uploaded ebuild to the sectools overlay. Question: Currently, we do: dosym /usr/lib/libcrypto.so.0.9.8 /usr/lib/libcrypto.so.0.9.7 Is any way to detect the current version of openssl from the nessus-bin ebuild?
Created attachment 145797 [details] nessus-bin-3.0.6-r1.ebuild with fixed openssl links
FYI, in Bug 187219 a new ebuild for a newer version has been submitted and it use RedHat's RPM which is built against OpenSSL 0.9.8. I guess we could make this bug depend on it. They do not specify the openssl version in their ebuild though which could lead to future problems....
Yes, go ahead and mark it. The new redhat version depends on different name of binaries and we do: dosym /usr/lib/libssl.so.0.9.8 /usr/lib/libssl.so.6 dosym /usr/lib/libcrypto.so.0.9.8 /usr/lib/libcrypto.so.6 So we expect it to fail if *.so.0.9.8 libraries don't exist.
Thomas, the new version of nessus-bin is in the portage. Please verify and close this bug if the problem solved.
I don't have that test system anymore, but since it's using the RedHat version it depends on symlinks (RH uses different library names for openssl). That version is build against 0.9.8 though. Marking as closed as there's nothing that can make me think it isn't.
