3

Redhat has this policy of backporting security fixes.

But then when RHEL and CentOS sites get audited, the auditors invariably just list the package versions or ask ssh what it's version number is, and then they fail you because you appear to be running a vulnerable version of, say, OpenSSH.

The only ways I can see to respond to this is are:

  1. Compile a list of RHEL security advisories, which would presumably show that the apparently-old rpm is in fact patched. I bet the auditor wouldn't actually read it though.
  2. Just install a newer package, even though it's pointless. This is a lot more difficult than it sounds, because the developer's package won't have init.d scripts and other integrations. And OpenSSH is hard to install on top of itself in a lights-out datacenter when it's your remote access method.

Is there a better idea?

There is something called OVAL. Redhat at least used to provide advisories in that format. Does it actually work on auditors?

DigitalRoss
  • 868
  • 1
  • 6
  • 15
  • 4
    If your auditor doesn't accept the Red Hat security advisory, you need a new auditor. Incompetence is something you should not tolerate in such an important position. – Michael Hampton Apr 20 '16 at 22:25
  • Ok, so that works? I haven't actually tried it... – DigitalRoss Apr 20 '16 at 22:26
  • 1
    Yes it works, unless the auditor is exceptionally unqualified to be a security auditor. This is part of our usual compliance process... – Michael Hampton Apr 20 '16 at 22:26
  • Consider that your auditor is flagging, say, openssh-6.6.1, as a risk; but you're on 6.6.1p1-27, which is more than 6.6.1. If your auditor can't see that 6.6 is newer than 6, 6.6.1 is better than 6.6, or 6.6.1p1-27 is better than 6.6.1p1, then that's a logic problem your auditor needs to deal with personally. Additionally, you CAN look up, by hand, each CVE the auditor thinks is a risk, show clearly how (eg) CVE-2015-8325 was addressed by 6.6.1p1-27 + 0.9.3-9, and move on until it's a list where the auditor disagrees with RedHat. Then it's between the auditor and RedHat, via your CTO. – user2066657 Aug 24 '17 at 04:59
  • 1
    and as well, DON'T EVEN THINK of installing some out of band thing like a stock openssh over top of your RPMs. The problems and work you've paid for, but will now be taking on personally as well, will be epic and tragic, and you will regret ever suggesting that to people who decide more than they know; and the regret may come sooner than later. – user2066657 Aug 24 '17 at 05:01

0 Answers0