I was recently contacted, and told that I should update some stuff on the server, because it had security holes. I figured I'd confirm that here, and perhaps get some help doing so.

First off, I was told that:
And then:

I'm slightly confused, but if anyone can confirm/shoot down these statements, please do so.

If I do need to upgrade SSH, how would I go about doing so? I've been Googling around and haven't found all that much helpful stuff.

It's running RedHat 7.2, and:

OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f.

Let me know if there's anything else you need to know.

Thanks in advance!

Wow, I can't believe they didn't say anything about your OpenSSL version, because that's vulnerable as well. It looks like that software hasn't been touched since the original install!

Your OpenSSH should be 3.7.1p2 or later, your BIND should be 9.2.3, your OpenSSL should be 0.9.6m, or 0.9.7d. Probably all the other software you have running is vulnerable to something as well (for instance there have been several vulnerabilities in Apache and it's modules, particularly PHP (mod_php).

You can either download the source to all of these and compile the new versions yourself (www.openssh.org, www.isc.org, www.openssl.org, www.apache.org, etc) or you can look on RPMfind.net (or rpmfind.speakeasy.net) to see if there are updated packages for old versions of Red Hat (it's doubtful that they will be recent enough, but you can try).

One thing about Red Hat that is frustrating is that they backport patches without bumping the version number, so you never know by the version whether a problem is fixed or not (for instance Red Hat backported the patches from OpenSSH 3.7.1p2 back to 3.5.1, so it appears it's still vulnerable even after you upgrade it).

ISC BIND, CA-2002-19
"CA" means "CERT Advisory": lookup format is www.cert.org/advisories/CA-YYYY-NR.html
This one is damn old and handles resolver buffer overflow situations in both DNS resolvers and Glibc. The way an exploit could work would be to for the attacker to ask for a process on your box to resolve an address for which a domain for she has taken control of the authoritative DNS so she can return a result that would exploit this condition. Note the advisory does not recognise running a caching nameserver as mitigation circumstances. IMHO the fact it usually isn't that easy to take over an authoritative DNS should not be seen as mitigating circumstances either.

Therefore you must immediately check if your RHL7.x box has a vulnerable version of Glibc, recompile any static apps that rely on Glibc's resolver and upgrade ISC BIND. The fact you're asking for confirmation on a two year old CERT Advisory isn't good. It means no one cared for upgrading the box, which makes it a liability for you, (the company you work for,) and everyone else. If you have no real reasons (businesswise) to stay with obsolete RHL, moving to RHEL, an RHEL clone, FC or any other current, supported vendor/distro combo would be advisable.


If I do need to upgrade SSH, how would I go about doing so? I've been Googling around and haven't found all that much helpful stuff.
Download OpenSSH from the main source. If you tar -t the tarball you'll notice it has a .spec file, which means "rpmbuild -ta <tarballname.extension>" should work. Before you do so, inspect the .spec file for SSL and Glibc version dependencies.