So, you have just failed your PCI compliance scan and been told that you are running an SSH server version from 2001 with 36 current vulnerabilities. At first glance, this is of course a severe cause for concern, and rightly so!
In some instances we have seen ASV (Approved Scanning Vendors) doing very little other than running a freely available tool against your server, banding its output and sent it to you as their analysis.
The drawback of this rather simplistic approach is that it’s very generic and applies next to no logic to its results.
What has happened in the case of the aforementioned SSH server is that it’s established a connection on port 22 to your server, and read the banner returned.
On a fully up to date RedHat Enterprise Linux (RHEL) 5 system, the banner reads SSH-2.0-OpenSSH_4.3. A look through the OpenSSH change log shows us that this version was conceived in March 2006.
Does this mean that you are vulnerable to all security holes discovered in OpenSSH since 2006? Of course not!
However, the scanning tools many PCI compliancy companies use do not actually test the vulnerabilities it is aware of, it just detects the version and bluntly assumes that the vulnerabilities are exploitable. If its database contains a vulnerability discovered in 2007, and your software version is from 2006, this can in some instances cause a failure of your scan.
So what’s going on then?
RedHat Enterprise Linux, among other distributions use something called backporting. In order to keep things compatible and stable, they don’t rebuild their packages with the new version every time a new patch or version is released.
What they do is they take the piece of code which plugs a security hole, and apply it to the older version and increment the build number of the package (NOT the version number). They therefore plug the hole, and avoid introducing new, potentially experimental features and/or changes in behaviour which potentially break our beloved and critical systems.
The idea behind RHEL is that once you’ve got your systems configured, they go very far in assuring that the behaviour of your platform remains the same throughout its supported life time.
If they simply upgraded every package to the latest version, it would contradict this philosophy and put that stability and availability at risk.
Another thing worth noting is that not only do some scanning tools only do version matching, it also does not take into consideration things it is unaware of. So if it detects that you are running, say, Apache httpd version 2.2.3 and there is a vulnerability for mod_ldap in that version, you will fail the scan even if that module isn’t loaded (or possibly even installed).
So in summary, if you have failed your PCI scan, don’t panic just yet, it’s often the norm and probably not your fault.