Ssh – If a CVE database lists the version of OpenSSH as vulnerable, is it possible that it has been patched but retains the version number

opensshvulnerability

I am using OpenSSH version 7.4p1, in CVE database I found that cpe:/a:openbsd:openssh:7.4:p1 is vulnerable to CVE-2017-15906 https://www.cvedetails.com/cve/CVE-2017-15906/.

Does this mean that for sure my version is affected or is it possible that this version has the same number but is already patched? How can I verify this?

Best Answer

CentOS is just rebuilt RHEL so your system is safe, if you updated to openssh-7.4p1-16.el7 or similar that is shipped in CentOS 7.

There is CVE database in Red Hat access portal:

https://access.redhat.com/security/cve/cve-2017-15906

With links to the erratas fixing the issues and with listing of packages fixing the specific issue:

https://access.redhat.com/errata/RHSA-2018:0980

Similarly you can get the changelog of your installed package and it should list something related to this CVE number.

Discaimer: I was fixing that package in this RHEL version.

Related Solutions

SSH won’t work before manually restarting networking.service

SOLVED! The machine is a Dell Poweredge system which ran what they call iDRAC in the background - iDRAC in its turn ran a SSH-server which conflicted with the one I installed in Debian. The solution for me was just to disable iDRAC since I don't use it, and I'm glad I don't. I have no idea how that conflict should've been solved.

Linux – How to secure Linux systems against the BlueBorne remote attack

The coordinated disclosure date for the BlueBorne vulnerabilities was September 12, 2017; you should see distribution updates with fixes for the issues shortly thereafter. For example:

Until you can update the kernel and BlueZ on affected systems, you can mitigate the issue by disabling Bluetooth (which might have adverse effects of course, especially if you use a Bluetooth keyboard or mouse):

blacklist the core Bluetooth modules

printf "install %s /bin/true\n" bnep bluetooth btusb >> /etc/modprobe.d/disable-bluetooth.conf

disable and stop the Bluetooth service

systemctl disable bluetooth.service
systemctl mask bluetooth.service
systemctl stop bluetooth.service

remove the Bluetooth modules
```
rmmod bnep
rmmod bluetooth
rmmod btusb
```
(this will probably fail at first with an error indicating other modules are using these; you’ll need to remove those modules and repeat the above commands).

If you want to patch and rebuild BlueZ and the kernel yourself, the appropriate fixes are available here for BlueZ and here for the kernel.

Best Answer

Related Solutions

SSH won’t work before manually restarting networking.service

Linux – How to secure Linux systems against the BlueBorne remote attack

Related Question