-2

I have a redhat server 7.5. I have a openssh installed on this server. The openssh is 7.4. I need to upgrade openssh 7.4 to 7.6 AS Nessus, vulnerability scanner scanned this vulnerability (Openssh <7.6) and thus need to upgrade to 7.6 or later.The details is found here, https://www.tenable.com/plugins/nessus/103781.

I found the link, https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/openssh-7.6.tar.gz but they said that this cannot be installed on Red Hat as you cant install bsd on Linux. I referred to this link, https://superuser.com/questions/577389/make-command-for-installing-openssh-on-ubuntu/

Thus I went to this link, http://www.openssh.com/portable.html to have a portable version. I used this link, https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-7.6p1.tar.gz.

I downloaded this file in /tmp directory.

I performed the following command,

# tar xvfz …/openssh-7.6p1.tar.gz
# cd ssh
# make obj    ←--------------------  error message
# make cleandir
# make depend
# make
# make install

I got this error when I performed the command make obj. The error is

make: *** No rule to make target 'obj'. Stop.
Improve this question
  • Can you add some details on this security reason? Red Hat usually issues advisories for such problems. – Haxiel Dec 6 '18 at 5:42
  • I scanned the server using nessus which is a vulnerability scanner and they said openssh is less than 7.6. The details is found here tenable.com/plugins/nessus/103781 – Abdullah Naina Dec 6 '18 at 5:45
  • Red Hat prefers to backport security fixes from upstream versions over version upgrades. Even when the exact versions don't match, the RHEL packages should be as secure as the upstream version. More details here: access.redhat.com/security/updates/backporting – Haxiel Dec 6 '18 at 5:50
  • 1
    I think a better approach to vulnerabilities detected by Nessus is to consider that they need to be investigated, but the fix suggested by Nessus isn’t always correct. A better question here might have been “How should I fix this vulnerability flagged by Nessus, on RHEL 7.5?”, without pre-supposing a solution (upgrading to the latest upstream version of OpenSSH, which isn’t appropriate on RHEL or indeed most distributions with long release cycles). – Stephen Kitt Dec 6 '18 at 9:04
  • 1
    @Abdullah no worries, vulnerabilities are often hard to evaluate and it takes a fair amount of experience to decide what to do, especially when faced with conflicting instructions (and no doubt some pressure from your management). – Stephen Kitt Dec 6 '18 at 10:23
2

The issue linked to in the comments refers to CVE-2017-15906 (listed on the same page).

Red Hat has documented this CVE along with its details, which is available here: https://access.redhat.com/security/cve/cve-2017-15906

According to the CVE page, an errata has been issued on this issue for RHEL 7 (RHSA-2018:0980). OpenSSH packages on RHEL 5 & 6 are not affected by this vulnerability. The errata is available here: https://access.redhat.com/errata/RHSA-2018:0980

As per the errata page, this security issue is fixed in the following version of OpenSSH and its related packages: 7.4p1-16.el7.x86_64. If you have this version of OpenSSH on RHEL 7, you should be safe from the vulnerability. More details on the change, including upgrade instructions, are available on the errata page linked above.

The latest version of OpenSSH as per the project's homepage is 7.9. Although the RHEL package is of a lower version, it still contains all of the security patches from the upstream version. This is done by backporting - isolating the security fixes from the upstream source, and then applying them to the older package that Red Hat distributes. This allows RHEL customers to continue using a specific version of a package, while being protected against new security vulnerabilities. More of this process is explained on this page: Backporting Security Fixes.

One of the problems with backporting is the version checks employed by security scanning tools (such as the Nessus Scanner, in this case). From the above link:

Also, some security scanning and auditing tools make decisions about vulnerabilities based solely on the version number of components they find. This results in false positives as the tools do not take into account backported security fixes.

This is precisely the case here, since the CVE-2017-15906 issue page for Nessus documents this explicitly:

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

Improve this answer

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