3

I've been trying to upgrade OpenSSH for PCI compliance on our company's web server. I cannot for the life of me figure out how to do this though.

I have attempted the following commands via SSH (coupled with their outputs):

# ssh -V
OpenSSH_5.3p1 Debian-3ubuntu7, OpenSSL 0.9.8k 25 Mar 2009

# sudo apt-get install openssh-server openssh-client
Reading package lists... Done
Building dependency tree
Reading state information... Done
openssh-server is already the newest version.
openssh-client is already the newest version.
The following packages were automatically installed and are no longer required:
  [list removed due to length]*
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 72 not upgraded.

# apt-get install openssh-server
Reading package lists... Done
Building dependency tree
Reading state information... Done
openssh-server is already the newest version.
The following packages were automatically installed and are no longer required:
  [list removed due to length]*
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 73 not upgraded.

*I removed the list so that this would be easier to read.

I'm not sure if this is relevant, but I also ran apt-get upgrade, and it seems as though updates were not done regularly on this system (I did not upgrade anything though, lest it break something from before). As I have zero system-admin experience before this job, I don't know if posting that information would compromise anything, so I will withhold from doing so unless necessary.

9
  • 1
    Just to note, people like Debian, RedHat, etc., will backport security fixes to their packages, without actually fully upgrading the software to the latest versions. This is to main version stability in their major releases. The PCI scan likely is only looking at the version number being reported. You should check the package changelog to verify that those specific vulnerabilities have been addressed. Likely, if you are up to date, there's nothing to do.
    – cjc
    Jan 22, 2014 at 13:49
  • @cjc I've seen that said a lot, but I wanted to try and upgrade it so that the next time I need to run the scan, I won't have to worry about all the steps and can just run the scan and be done with it. Also, I made a mistake--the server has Ubuntu installed. I'm sure your statement is still applicable, but I would prefer, as I said, to install it to make it easier for future scans.
    – jperezov
    Jan 22, 2014 at 14:04
  • 1
    I think that the "73 not upgraded" message should be more important. Also, tell those PCI to actually try to exploit the ssh port instead of relaying in the version string.
    – Braiam
    Jan 22, 2014 at 16:02
  • @user3191820 The problem with upgrading it fully is that you may have to take on the responsibility of keeping it upgraded, possibly in terms of building your own packages (though, with openssh, there's probably some repo somewhere that will have recent versions in packages), or relying on a much smaller entity that Canonical to keep putting out up-to-date packages. It really is better to rely on Canonical/Ubuntu to do their backports the way they feel like it, and then just put an asterisk on the PCI scan. You really don't want to maintain your own packages.
    – cjc
    Jan 22, 2014 at 17:59
  • 1
    Just for your information, you may see what package are affected by a CVE, and whether patch had been backported or not here: people.canonical.com/~ubuntu-security/cve Jan 23, 2014 at 19:40

1 Answer 1

7

Just to note, people like Debian, RedHat, etc., will backport security fixes to their packages, without actually fully upgrading the software to the latest versions. This is to maintain version stability in their major releases (i.e., if you are running RHEL 6.5, you will be running OpenSSH 5.3p1, even though OpenSSH 6.4 is currently available).

The PCI scan likely is only looking at the version number being reported. You should check the package changelog to verify that those specific vulnerabilities have been addressed (i.e., CVE-xxxx is being flagged by the scan and it affects version 5.4; the package changelog will say that the fix for that CVE was backported on such-and-such date to 5.3p1). Likely, if you are up to date, there's nothing to do.

You can install the latest and greatest OpenSSH (or any other piece of software) to fulfill the PCI requirements. No one will stop you from doing that. The problem with this approach is that you may have to take on the responsibility of keeping your custom installed software upgraded, possibly in terms of building your own packages (though, with openssh, there's probably some repo somewhere that will have recent versions in packages), or relying on a much smaller entity that Red Hat or Canonical to keep putting out up-to-date packages. What tends to happen in this case is that new vulnerabilities will come out, and unless you pay attention, you will start falling behind. It's better to rely on someone whose job it is to keep things up to date, and to make sure that there is a QA process to show that nothing will break. Let the people at Red Hat, Canonical, etc., do their jobs and apply their backports the way they feel like it, and then just put an asterisk on the PCI scan. You really don't want to maintain your own packages.

From a management point of view, the PCI scanner should be seen as a tool to help show where you may have vulnerabilities; what you do with the results of your (somewhat blunt) tool is more of a managerial decision (i.e., if this is internal, then you just make a note within your own company that this issue is fixed regardless of what the scan report shows; if it's for external use, you need to communicate to the interested parties that the issue is already fixed, and that you are not going to stray from Ubuntu packaging because that's a worse option.) You can have better knowledge of your systems than a general purpose scanner.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .