Bugzilla Bug 189879

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 an attachment (id=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.