Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
jberg712
Collaborator
Jump to solution

OpenSSH Vulnerability detection

Hi,

I've been digging through information in regards to the vulnerabilities in OpenSSH that were found during our vulnerability and penetration testing.  We currently run R81.20 which has OpenSSH 7.8.  I've also been reading some of the other posts in the community.  OpenSSH upgrade R81.10 - Check Point CheckMates

Below OpenSSH 8.0 has the following CVE's reported.

CVE-2018-20685
CVE-2019-6109
CVE-2019-6110
CVE-2019-6111

Below OpenSSH 9.6 reports the follwing CVE's:

CVE-2023-48795
CVE-2023-51384
CVE-2023-51385

Now I've been reviewing SK65269 sk65269 - Status of OpenSSH CVEs and the list of OpenSSH CVE's.  CheckPoint has indicated that some of these are deemed "Vulnerable - but not exploitable'

I wanted to raise the questions

1.  What does "Vulnerable - but not exploitable" actually mean?  Does it mean that even though the version is vulnerable, it cannot be exploited?  If this is true, is there any other information or data available that supports this?  On paper, to see the word 'vulnerable' even though it's not exploitable still raises questions and concerns for the higher ups on such a vague and somewhat seemingly contradictory response.  The clarification's at the bottom do not have an explanation to this status.

2.  Why is Check Point not actively updating these components?  I get that some of the responses state that this is a low risk and that the odds of this ever being exploited are low, however, it has always been the practice that one of the best resolutions in cybersecurity for any vulnerability is to patch it.  Again, I understand "low risk", but it's still "risk".  Ideally we want to eliminate "risk" as much as possible.  So why can't CheckPoint include the fixed OpenSSH versions and not have this come up?  And at some point are they?

0 Kudos
2 Solutions

Accepted Solutions
_Val_
Admin
Admin

In general, Check Point is very serious about product vulnerabilities. The Critical and High CVEs are fixed in a record time, especially when compared against competitors. Now, to address your questions:

1. "Vulnerable - but not exploitable" means that although a specific component might be vulnerable to an attack, it cannot be exploited, even theoretically, as part of specific Check Point products. Usually it is the case for those parts of external libraries which are not in use, although present.

If you cannot take a responsible reporting from the vendor as trusted and require additional proof, you can always request additional information via a TAC ticket or by reaching out to your local Check Point office.

2. Check Point always updates or even provides custom patches for those CVEs that present a significant risk to our customers. If you are not familiar with the scoring system, take a look here; there is a decent explanation of how it is assessed. 

There is always a risk for any information or network system, it is never zero. A "low risk" CVE score, generally in the range of 0.1 to 3.9, indicates a vulnerability with minimal severity. It means the impact on an organization's operations would be very limited at best, and most probably will just cause an inconvenience. Exploiting these vulnerabilities typically requires local or physical access to the system. 

In other words, having an admin password for your firewalls in the hands of a rogue admin is a higher risk than a low vulnerability  CVE. If it can only be exploited by accessing your system with an admin password, it is more a question of whether you trust your engineers and administrators.

I hope this makes sense. Let me know if you have more questions.

 

View solution in original post

PhoneBoy
Admin
Admin

Upgrading one component to a new version often requires upgrading other software components, which may create integration issues.
As such, if we upgrade the version of a component like OpenSSH, it's only done as part of a version upgrade.
Having said that, we do apply the relevant security patches to the underlying components as part of the JHF.

View solution in original post

4 Replies
the_rock
Legend
Legend

1) In my mind, what that really means is that something is indeed vulnerable, but way to exploit that is literally non-existent.

2) I really cant answer that question, you should probably ask your local SE or open TAC case to get an official answer.

Andy

0 Kudos
_Val_
Admin
Admin

In general, Check Point is very serious about product vulnerabilities. The Critical and High CVEs are fixed in a record time, especially when compared against competitors. Now, to address your questions:

1. "Vulnerable - but not exploitable" means that although a specific component might be vulnerable to an attack, it cannot be exploited, even theoretically, as part of specific Check Point products. Usually it is the case for those parts of external libraries which are not in use, although present.

If you cannot take a responsible reporting from the vendor as trusted and require additional proof, you can always request additional information via a TAC ticket or by reaching out to your local Check Point office.

2. Check Point always updates or even provides custom patches for those CVEs that present a significant risk to our customers. If you are not familiar with the scoring system, take a look here; there is a decent explanation of how it is assessed. 

There is always a risk for any information or network system, it is never zero. A "low risk" CVE score, generally in the range of 0.1 to 3.9, indicates a vulnerability with minimal severity. It means the impact on an organization's operations would be very limited at best, and most probably will just cause an inconvenience. Exploiting these vulnerabilities typically requires local or physical access to the system. 

In other words, having an admin password for your firewalls in the hands of a rogue admin is a higher risk than a low vulnerability  CVE. If it can only be exploited by accessing your system with an admin password, it is more a question of whether you trust your engineers and administrators.

I hope this makes sense. Let me know if you have more questions.

 

PhoneBoy
Admin
Admin

Upgrading one component to a new version often requires upgrading other software components, which may create integration issues.
As such, if we upgrade the version of a component like OpenSSH, it's only done as part of a version upgrade.
Having said that, we do apply the relevant security patches to the underlying components as part of the JHF.

the_rock
Legend
Legend

You got great answers by both Val and Dameon.

Andy

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events