3

A common problem is that Redhat backports security fixes leaving OpenSSH with an old, but not vulnerable, rpm version and ssh version string on Redhat and CentOS. This fools auditors.

Apparently, the solution is to provide the Redhat SAs to the auditor. But which ones? How exactly do I do this? Do I need to compile an SA for every vulnerability?

(What I'm trying at the moment is upgrading to the rpm most recently listed in a SA, then just providing the most recent SA should demonstrate the most recent package fix.)

1

Providing the SA and version should be good enough since the SSH patch has been implemented. If they have problems with this then they would have to take it up with Redhat version control themselves.

After all if you can demonstrate that the attack will not work because it has been patched, version number means nothing. It's already patched regardless of what the version says.

0

What you need to address is the issue, and whether or not the issue is fixed, or if there is a compensating control to address the vulnerability. If there isn't a patch for a vulnerability, you would be out of compliance however if you had rules that illustrated that you blocked all, but allowed only trusted (vetted sources) you now have a compensating control. So while you're relying on Redhat to issue an update, depending on what the issue is with SSH, you may be able to create rules in hosts.deny or firewall rules to minimize the risk. It all depends on your approach. There is no definitive answer. Providing Redhat SAs do little since they could come from anywhere (any system, even a pastebin copy). Showing what you did to minimize the risk/impact should suffice to auditors in the event a patch is not available.

  • I'm sorry if I wasn't clear, but you've misunderstood the problem. All the vulnerabilities are fixed via the backports. The question is, given the Redhat approach: how do I demonstrate this in an audit? – DigitalRoss Apr 20 '16 at 23:22
0

Redhat provides the necessary CVE to package version information.

For any provided CVE the package version may (and as I have found in my own experience) may not correspond to the original package version. Example source from developer for package ABC is v0.0.3 which addresses CVE 1.1 where RedHats RPM of ABC is at v0.0.2x for release 6 and at v0.0.3 for release 7.

The real problem with an audit of this type would require a little extra leg work to ensure conformity due to the necessity of cross refencing the RPM version with the vendors release and security notes.

The easiest method IMHO would be to check the RPMS for the affected package, cross reference the original package code which addresses the CVE and make sure it exists in the RPMS.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.