Did someone a vulnerability scan against R80.10 Mgmt and GW? (Update: R80.20 GA)

[Alexander_Wilke]

Hi,

we installed R80.10 MDS and GW in our lab and I had a short look ond the system and found out that the PostgreSQL databse on the MDS has version 9.2.4 and version 9.2.19 will be end of life in september 2017.

Are there other people having security concerns about the implemented software products and perhaps already did a vulnerability scan?

We are planning to do so but I would be interested in how other CheckPoint users think and feel if they know that a product which will be released soon is using old and nearly outdated software products?

Kind regards

[Alexander_Wilke]

Hello,

more than 1 year has passed and CheckPoint released new R80.20 but vulnerabilities are still the same and noone cares. What do you think about that? Do you experience the same?

I did this last week on R80.20 GA:

PostgreSQL Database:

[Expert@l504lfmg0101l:0]# cpstat os

Product Name:                  SVN Foundation
SVN Foundation Version String: R80.20
SVN Foundation Build Number:   992000010
SVN Foundation Status:         OK
OS Name:                       Gaia
OS Major Version:              3
OS Minor Version:              10
OS Build Number:               -
OS SP Major:                   -
OS SP Minor:                   -
OS Version Level:
Appliance SN:                  To Be Filled By O.E.M.
Appliance Name:                Smart-1 50
Appliance Manufacture:         CheckPoint

[Expert@l504lfmg0101l:0]# ./psql -V
psql (PostgreSQL) 9.2.4
[Expert@l504lfmg0101l:0]#

Here are the EOL dates fpr postgresql:
https://www.postgresql.org/support/versioning/https://www.postgresql.org/support/versioning/

How can CheckPoint fix vulnerabilities of the database will not be supported anymore?

Further I had a look at these configuration files - this is not a security topic but a performance topic.

• /opt/CPshrd-R80/database/postgresql/data/postgresql.conf
• /opt/CPshrd-R80/database/postgresql/cppostgres.conf

and these parameters:

• shared_buffers
• temp_buffers
• work_mem
• maintenance_work_mem
• effective_cache_size

It would make sense to have a configuration script which checks the hardware parameters like RAM and then adjusts the postgresql.conf configuration files based on this. I don't know if this is something R80.20 is already doing but if not it would lead to wasted ressources which will not be used because the database is not aware of that. I am pretty sure it should make a difference in the configuration files if you are using a SMART-1 50 with 8GB RAM or a SMART-1 3150 with up to 256GB RAM.

Weak Hashing algorithm for Gaia password:

##########
[Expert@l504lfmg0101l:0]# dbget -rv passwd | grep '[$]'

passwd:admin:passwd $1$78lihOay$v1WQincbLJwSZti3MwJDK.
[Expert@l504lfmg0101l:0]#
[Expert@l504lfmg0101l:0]# cpstat os

Product Name:                  SVN Foundation
SVN Foundation Version String: R80.20
SVN Foundation Build Number:   992000010
SVN Foundation Status:         OK
OS Name:                       Gaia
OS Major Version:              3
OS Minor Version:              10
OS Build Number:               -
OS SP Major:                   -
OS SP Minor:                   -
OS Version Level:
Appliance SN:                  To Be Filled By O.E.M.
Appliance Name:                Smart-1 50
Appliance Manufacture:         CheckPoint

[Expert@l504lfmg0101l:0]#

sk114745 described it but is not available anymore.

Files like PNG, JPG, HTML with executeable permissions:

We addressed this in 2015/2016 with R77.10 and we got a Letter of Intent (JSQ-290-51954) for that:

###################
[Expert@l504lfmg0101l:0]# find / -type f -iname "*jpg" -perm /u=x,g=x,o=x 2>/dev/null
/opt/CPrt-R80.20/data/EventDetails/images/right_bottom_corner.jpg
/opt/CPrt-R80.20/data/EventDetails/images/right_top_corner.jpg
/opt/CPrt-R80.20/data/EventDetails/images/top_banner.jpg
/opt/CPrt-R80.20/data/EventDetails/images/header-bg.jpg
/opt/CPrt-R80.20/data/EventDetails/images/html_top.jpg
/opt/CPrt-R80.20/data/EventDetails/images/left_bottom_corner.jpg
/opt/CPrt-R80.20/data/EventDetails/images/left_top_corner.jpg
[Expert@l504lfmg0101l:0]#
###################

Letter of Intent (JSQ-290-51954):
#####
Requested feature:
Remove executable permissions of irrelevant files
Delivery:
Check Point plans to fix executable permissions issue in a major version of the main product, or a
special customer release, which will be released in 2016.
If the fix of executable permissions issue is not be released due to technical reasons, a new date and
a new release will be provided according to the Check Point priorities at the time
#####

Support ASLR/Canary and RELRO compiler settings

We addressed this in 2015 and I am not sure if this is fixed in the new R80.20 GA.

Letter of Intent (TGN-477-60852):
#####
December 2015.
Check Point Solution Center
Check Point plans to support ASLR/Canary and RELRO compiler settings as part of the roadmap.
Requested feature:
Compile the Check Point source code with gcc, which supports ASLR/Canary and RELRO settings.
Delivery
Check Point plans to support ASLR/Canary and RELRO compiler settings in a major version of the main product, or a special customer release, which will be released in 2017.
If support of ASLR/Canary and RELRO compiler settings is not be released due to technical reasons, a new date and a new release will be provided according to the Check Point priorities at the time
#####

I would really appreciate any feedback how do you feel when you address such topics, you get positiv feedback but no results?

Kind regards

Alexander Wilke

[Marco_Valenti]

would be nice to ear more from cp on those issue

[AlekseiShelepov]

Aren't you worried that Check Point is just migrating Gaia to 3.10 kernel in R80.20 version, support for which has ended on November 2017? Previously it was based on 2.6 kernel, support for the latest versions of it has ended in 2016.

[Alexander_Wilke]

Hi,

implementing a new kernel into a product probably is not that easy. I am not familar with RHEL EOL plans but it looks like that RHEL 7 is supported longer:
Red Hat Enterprise Linux Life Cycle - Red Hat Customer Portal 

So probably there are chances to get backport fixes for the used kernel.

[Alexander_Wilke]

Hi again,

found another thing when I tried to configure (secure) SSH ciphers and Key-Exchange algorithms:

Outdated OpenSSH 4.3p2 with hardcoded ciphers and keyexchange algorithms:

R77.30 with recent JHFA T336:
####

[Expert@l504lab0102l:0]# cpstat os

Product Name: SVN Foundation
SVN Foundation Version String: R77.30
SVN Foundation Build Number: 990180083
SVN Foundation Status: OK
OS Name: Gaia
OS Major Version: 2
OS Minor Version: 6
OS Build Number: -
OS SP Major: -
OS SP Minor: -
OS Version Level:
Appliance SN: 1325B00221
Appliance Name: Check Point 12200
Appliance Manufacture: CheckPoint

[Expert@l504lab0102l:0]# installed_jumbo_take
R77.30 Jumbo Hotfix Accumulator take_336 is installed, see sk106162.
[Expert@l504lab0102l:0]#
[Expert@l504lab0102l:0]# ssh -V
OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
[Expert@l504lab0102l:0]#

####

And this is R80.20 GA - with updated (not up to date) OpenSSL version but still the same very old SSH version:

#####

[Expert@l504lfmg0101l:0]# cpstat os

Product Name: SVN Foundation
SVN Foundation Version String: R80.20
SVN Foundation Build Number: 992000010
SVN Foundation Status: OK
OS Name: Gaia
OS Major Version: 3
OS Minor Version: 10
OS Build Number: -
OS SP Major: -
OS SP Minor: -
OS Version Level:
Appliance SN: To Be Filled By O.E.M.
Appliance Name: Smart-1 50
Appliance Manufacture: CheckPoint

[Expert@l504lfmg0101l:0]#
[Expert@l504lfmg0101l:0]#
[Expert@l504lfmg0101l:0]# ssh -V
OpenSSH_4.3p2, OpenSSL 1.0.2n 7 Dec 2017
[Expert@l504lfmg0101l:0]#

#####

I don't know if OpenSSH is used for internal CheckPoint processes or not but I assume that it is only there for admin access and so I do not see why it should be a problem to update OpenSSH.

Regards

[PhoneBoy]

Generally speaking, for any version we ship and is covered under an active agreement, we will provide security updates for underlying components as needed.

For Postgres in particular, we do not expose it as a general-purpose database.

The only way to interact with it is the API server, which only interacts with it on localhost.

This limits the potential attack surface to expert mode.

And, lets face it, in expert mode, a malicious actor can do a lot more damage.

R80.20 does include support for SHA2 password hashes, however the default is still MD5.

You can set it via the clish command show password-controls password-hash-type and it will apply for all passwords set from that point forward.

Note that a given component (e.g. OpenSSH) relies on other components, making it a little more involved to update a given component than it appears on first glance.

We do plan to update some of these components in later releases.

If you have been given letters of intent on specific issues that have not been resolved, I recommend you follow up with your local office.

[Marco_Valenti]

There is a chance that this feature will be available in the future for r77.30 gateway too?

Thanks

[PhoneBoy]

I assume you mean SHA2 password hashes?

I believe there may be customer releases that add this, you should check with your local office.

[Marco_Valenti]

thanks for the reply Dameon