We are running RHEL 4.4 WS with Openssh 3.9p1.
Site security requirements dictate that we run a version of Openssl newer than 0.9.7c. Boss does not want us to compile it. He wants us to find the binary and libs and install them. Trouble is, I can't find anything but source. I have looked in freshmeat, updates.redhat.com, openssl.org, and rpmfind.net.

Does anybody know where I can find an openssl-0.9.7d or newer package?

TIA,
Linda

Normally I'd move distro-specific questions like this to their distribution's LQ forum, but considering the HUGE security implications of what you are doing, I'm leaving it here for a while. IMHO, the way your boss has you going about this is a a very serious security risk. Official (and digitally-signed) binary packages provided by your distributor are great. But going around the WWW in search of unofficial binaries to install can cost you your job in a lot of places - for good reason.

Is there some *specific* vulnerability which isn't taken care of in your distro's latest patched OpenSSL package? Keep in mind that with binary OpenSSL packages it's a common practice to backport security fixes and leave the main version number/letter alone. In such cases, you need to actually look at the changelogs to see what vulnerabilities have been patched. For example, when your distributor (Red Hat, Inc.) released updated OpenSSL packages to fix CVE-2006-3738, the package was still called openssl-0.9.7a, even though the upstream fix by OpenSSL.org was included in version 0.9.7l.

Take a look at the Red Hat Errata. The version you are running is more updated than 0.9.7c Red Hat backports all the security patches for there programs. The only way to go to 0.9.7c and not mess with your support contract is to upgrade to RHEL5. I am guessing that the company has something to do with the GOVT requirements. We had the same exact requirement but the errata has all the CVE numbers and all the security patches.

here is the specific link for rhel4 openssh changelog. This shows everything that was patched.


https://rhn.redhat.com/network/softw...pxt?pid=404682

but you must have a red hat network login.
i hope this helps

"it's a common practice to backport security fixes and leave the main version number/letter alone."

and

"For example, when your distributor (Red Hat, Inc.) released updated OpenSSL packages to fix CVE-2006-3738, the package was still called openssl-0.9.7a, even though the upstream fix by OpenSSL.org was included in version 0.9.7l."

I don't get that. If you are going to get into the system/program to correct it, update a library, make a change, whatever...why not just go ahead and update the version # while you are there? How hard is that? And why would you call a package 097a when it is really 097l?

So you have to dig thru a log to figure out what the REAL version is based on what CVE was fixed or not fixed. I wonder where that change log is. Oops my Solaris/HP background is showing. And why would an update to a piece of 3rd party software/library "mess" with my service contract?

Yes, I am new to Linux and am still trying to decipher the umpteen flavors, multiple subversions (WS, AS, ES, et al) to those flavors and hardware specific (i386, IA_64 etc). I can only hope that these RPMs are with the change log in this open-source quagmire. This is, of course, assuming that the errata/change log is ON my system. find and grep are my friends.

I logged into my predecessor's redhat account and found a section called relevant errata with 109 entries. Are those patches? Who knows?

My lack of turn-over is starting to strangle me. I don't even know where to start. I have bought every Redhat/Linux book I can find and there is no clear process for updating other than up2date. So if your box does not connect to the cloud, how are you supposed to get your updates or even know which ones to grab?

OK, I'm done ranting. Thanks for your help. What I really need is a turn-over but the guy left months before I got here.

Typically this is done whenever stability is paramount, as is the case with "enterprise" distros such as RHEL. The distributor wants to make as little changes to binaries as possible, which almost always translates into "security fixes only" and maybe "extremely critical bug fixes" too. My understanding is that by not tampering with the main version number, it is an indicator that the feature set remains the same. The version number for the package itself (the numbers further to the right in the file name) does increase every time an update is made, of course. As a bonus, not making major changes to a library also lessens the chance that binaries which use it will have to be recompiled against it.

Not exactly. If only security/critical fixes are being applied to the distro's package, it's unlikely there will be an upstream equivalent. The upstream developers don't need to be concerned with stability the way "enterprise" distributors do - they can add all the new features they want.

As for the other Red Hat-specific questions in your rant, I'll defer to someone else, as I'm not that familiar with the ways of RHEL.

Win32sux - thank you for your kind reply. It gives me insight into how this is supposed to work. A bit different from what I've done in the past but I'm trying to learn.

I've cooled off some now that I have examined the CVEs and found that they do not apply to RH 4.4. All that fussing for naught.

But I would still like to understand where the rpms and change log are stored on my system.

And when I go to my redhat account, those 109 items, are those the patches for my registered versions? Following that thought, would I download only the critical ones (ie Mozilla) and apply them one-sy two-sy or is there a cluster method? What do real Linux sysadmins do? I would like to protect my systems but who wants to download/install unnecessary patches?

Any help on those two questions and I'll be doing my happy dance.

Thanks,
Linda

Well, you can look at the installed RPMs by using the rpm command, like:As for changelogs, look for a /usr/share/doc or /usr/doc directory. There should be changelogs in the relevant package's subdirectory.

For example, this is what the OpenSSL doc directory looks like on my Ubuntu box:
I would suggest these manuals as a good place to get answers to these questions direct from the source:

Red Hat Enterprise Linux 4 - Introduction to System Administration

Red Hat Enterprise Linux 4.5.0 - System Administration Guide

Red Hat Enterprise Linux 4.5.0 - Security Guide

Win32sux,
Thank you so much for your reply. And for the advice on the online books. I wish they gave an option to print or buy these, I like to scribble notes in my tech manuals to help me remember. These docs are all good resources for me. With your help, I have found the change log. Thanks, again.
Linda