- Products
- Learn
- Local User Groups
- Partners
- More
Welcome to Maestro Masters!
Talk to Masters, Engage with Masters, Be a Maestro Master!
Join our TechTalk: Malware 2021 to Present Day
Building a Preventative Cyber Program
Be a CloudMate!
Check out our cloud security exclusive space!
Check Point's Cyber Park is Now Open
Let the Games Begin!
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
CheckFlix!
All Videos In One Space
Hello,
Just wanted to ask for a statement from Check Point regarding CVE-2019-11477, CVE-2019-11478 & CVE-2019-11479. As redhat posted a statement and mentioned several releases are affected my guess is, that Check Point with GAiA is affected too (as based on RH Linux...).
Details can be read below:
https://access.redhat.com/security/vulnerabilities/tcpsack
Regards,
Maik
That is easy: If you read the script, you find the kernel versions that are affected. If you comment put the RHEL 5-8 only lines, you get:
Check Point Security Gateway R80.30
Kernel 2.6.18-92cpx86_64
Edition 64-bit
Build 200
---
This script (v1.0) is primarily designed to detect CVE-2019-11477 on supported
Red Hat Enterprise Linux systems and kernel packages.
Result may be inaccurate for other RPM based systems.
Running kernel: 2.6.18-92cpx86_64
This system is Not affected
---
Check Point Security Management R80.30
Kernel 3.10.0-693cpx86_64
Edition 64-bit
Build 200
---
This script (v1.0) is primarily designed to detect CVE-2019-11477 on supported
Red Hat Enterprise Linux systems and kernel packages.
Result may be inaccurate for other RPM based systems.
Running kernel: 3.10.0-693cpx86_64
This system is Not affected
That's not how the script works. The script has a list of vulnerable RHEL kernels and checks uname -r versus this list.
Obviously only original RHEL kernels are included in the list, so you'll always get "not vulnerable" from that script for systems that have change the release string. That's the reason the script checks for el[5-8] before running - it's only valid for RHEL and maybe CentOS.
There are kernel releases in the list that are similar to the current gateway release kernel (2.6.18-92) as well as the current management kernel (3.10.0-693).
user@linux:~> grep 2.6.18-92 cve-2019-11477--2019-06-17-1629.sh
'2.6.18-53.1.21.el5' '2.6.18-92.el5' '2.6.18-92.1.1.el5' '2.6.18-92.1.6.el5' '2.6.18-92.1.10.el5'
'2.6.18-92.1.13.el5' '2.6.18-92.1.17.el5' '2.6.18-92.1.18.el5' '2.6.18-92.1.22.el5' '2.6.18-128.el5'
user@linux:~> grep 3.10.0-693 cve-2019-11477--2019-06-17-1629.sh
'3.10.0-693.el7' '3.10.0-693.1.1.el7' '3.10.0-693.2.1.el7' '3.10.0-693.2.2.el7' '3.10.0-693.5.2.el7'
'3.10.0-693.5.2.p7ih.el7' '3.10.0-693.11.1.el7' '3.10.0-693.11.6.el7' '3.10.0-693.17.1.el7' '3.10.0-693.21.1.el7'
'3.10.0-693.25.2.el7' '3.10.0-693.25.4.el7' '3.10.0-693.25.7.el7' '3.10.0-693.33.1.el7' '3.10.0-693.35.1.el7'
'3.10.0-693.37.4.el7' '3.10.0-693.39.1.el7' '3.10.0-693.43.1.el7' '3.10.0-693.44.1.el7' '3.10.0-693.46.1.el7'
'3.10.0-693.47.2.el7' '3.10.0-861.el7' '3.10.0-862.el7' '3.10.0-862.2.3.el7' '3.10.0-862.3.2.el7'
'3.10.0-693.rt56.617.el7' '3.10.0-693.2.1.rt56.620.el7' '3.10.0-693.2.2.rt56.623.el7' '3.10.0-693.5.2.rt56.626.el7' '3.10.0-693.11.1.rt56.632.el7'
'3.10.0-693.11.1.rt56.639.el7' '3.10.0-693.17.1.rt56.636.el7' '3.10.0-693.21.1.rt56.639.el7' '3.10.0-861.rt56.803.el7' '3.10.0-862.rt56.804.el7'
'3.10.0-514.rt56.221.el6rt' '3.10.0-514.rt56.228.el6rt' '3.10.0-514.rt56.231.el6rt' '3.10.0-693.2.1.rt56.585.el6rt' '3.10.0-693.2.2.rt56.588.el6rt'
'3.10.0-693.5.2.rt56.592.el6rt' '3.10.0-693.11.1.rt56.597.el6rt' '3.10.0-693.11.1.rt56.606.el6rt' '3.10.0-693.17.1.rt56.604.el6rt' '3.10.0-693.21.1.rt56.607.el6rt'
'3.10.0-693.25.2.rt56.612.el6rt' '3.10.0-693.25.4.rt56.613.el6rt' '3.10.0-693.25.7.rt56.615.el6rt' '3.10.0-693.33.1.rt56.621.el6rt' '3.10.0-693.35.1.rt56.625.el6rt'
'3.10.0-693.37.4.rt56.629.el6rt' '3.10.0-693.39.1.rt56.629.el6rt' '3.10.0-693.43.1.rt56.630.el6rt' '3.10.0-693.44.1.rt56.633.el6rt' '3.10.0-693.46.1.rt56.639.el6rt'
'3.10.0-693.47.2.rt56.641.el6rt'
As nobody knows from what sources and patches Check Point builds its packages, only Check Point can tell about the impact of Sad SACK.
Of course, the script states loud and clear that it can only talk about RHEL kernels - GAiA kernel is CP.
Could it be that the script doesn't know about the custom Checkpoint kernels?
In the script it shows a lot of entries in the 2.6.18-92 range.
To protect devices behind the firewall that run an unsafe RedHat kernel version, see here: https://access.redhat.com/security/vulnerabilities/tcpsack
Given that these were disclosed on 2019-06-17, it is a bit premature to expect the IPS protection to be available 24 hours later.
Wishful thinking perhaps, but unlikely to happen.
As there's only one kernel running on VSX, it would be a global setting. You cannot even set it per interface. This is a Linux limitation, not a Check Point one.
However, performance impact should be very low when exposed connections that don't have a high packet loss rate, as Selective ACK only plays a role in scenarios where you lose TCP packets.
to add to @PhoneBoy's answer, VSs are running firewalls in User Mode. Kernel is for the whole environment, hence the parameters mentioned on our response SK will affect all VSX system at once.
sk156192 states for CVE-2019-11477, that only management servers are effected. Gateways are not listed, contrary to the other two CVEs.
Can you confirm that no gateways are effected by CVE-2019-11477?
Please see updated SK detailing which versions have been patched and are still in progress: sk156192
R80.10 & R80.20 are patched with the latest jumbo hotfix while others are still in progress.
Great to hear/see that there are patches already available:
- R77.30 JHF 351 (included in JHF)
- R80.10 TCP SACK PANIC Hotfix , which should be installed on top of JHF 203 (General availability)
- R80.20 JHF 87 (Ongoing take)
- R80.30 JHF 19 (Ongoing take)
But I do have some questions:
Thanks!
Already mentioned: how to protect servers behind firewall? I could patch or apply workaround on gateways, but on servers, where are applications running, such is much more demanding task. I was looking for possibility of blocking possible attack on firewall, only hoping, that IPS signature was already updated (did not find any information confirming it). How about situation, where IPS is not in use? In theory dropping packets with low MSS might help, sort of "iptables -A INPUT -p tcp -m tcpmss --mss 1:500 -j DROP". How to achieve such in safe way on firewall?
I saw that these CVEs are fixed in Hotfix 351.
Can anyone tell when this Hotfix will be generally available?
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY