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.

jperezov
  • 133
  • 1
  • 7
  • 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 '14 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 '14 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 '14 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 '14 at 17:59
  • @cjc Your argument is rather convincing. Is this what I need to show: http://changelogs.ubuntu.com/changelogs/pool/main/o/openssh/openssh_5.9p1-5ubuntu1/changelog? I'm not really sure if I should just take this question elsewhere, since I don't know how to send the information to the PCI 3rd party scanner. – jperezov Jan 23 '14 at 14:37
  • Yes, that's it. In the report, you will see that CVE-xxxx is a vulnerability in openssh-yyyy, and you need to have that find it as fixed in the changelog. The PCI scanner is a tool; what you do with the results of your 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. – cjc Jan 23 '14 at 16:14
  • Thanks a bunch for your help. Although it doesn't necessarily answer the question I had, your answer did solve my problem. I'll check it as the "correct" answer if you post it, since it will probably help out others who come across this page. I've seen such answers before, but nothing explaining that straying from the packaging has worse consequences than doing the updates yourself. – jperezov Jan 23 '14 at 16:31
  • @user3191820 OK, posted as an answer – cjc Jan 23 '14 at 18:56
  • 1
    Just for your information, you may see what package are affected by a CVE, and whether patch had been backported or not here: http://people.canonical.com/~ubuntu-security/cve/ – Raymond Tau Jan 23 '14 at 19:40

1 Answers1

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.

cjc
  • 24,916
  • 3
  • 51
  • 70