<<< Date Index >>>     <<< Thread Index >>>

Re: RE: CheckPoint Secure Platform Multiple Buffer Overflows



Hi Mr. van der Kooij, 

please let me call you in this way as Hugo talking with Hugo -Vazquez- sounds a 
bit confusing... :-)

Regarding with this:

>I think however that Check Point consideres >everyone with access to a
>Secure Platform system to be a trusted user. So >they will not regard these
issues with the priority you (Hugo Va¿½zqu) seem to bestow on it.

Right now -16 October 2007- Check Point as already  accepted the flaws. 
Regarding to the privilege escalation to the "Expert" mode -standard root-, I 
should tell again that that is the minor problem. If you read the paper you 
will see that there are things more interesting to explore... Anyway, today, 
"googleing" a bit I found an interesting URL of the NIST:
"FIPS 140-2 Non-Proprietary Security Policy"
http://csrc.nist.gov/cryptval/140-1/140sp/140sp420.pdf

This doc is no more available online, but you can have the cached version... 
If you read you will see: "This is a non-proprietary Cryptographic Module 
Security Policy for Checkpoint Software Technologies Ltd."
(...)
"This security policy
describes how the Check Point VPN-1 version NG with Application Intelligence 
meets the security requirements of FIPS 140-2 and how to run
the module in a secure FIPS 140-2 mode. This policy was prepared as part of the 
Level 2 FIPS 140-2 validation of the module."

It's an interesting document. There's more info about FIPS and it's relation 
with Common Criteria here: 
http://csrc.nist.gov/groups/STM/cmvp/index.html#05

On that link you can read:
"The Common Criteria (CC) and FIPS 140-2 are different in the abstractness and 
focus of tests. FIPS 140-2 testing is against a defined cryptographic module 
and provides a suite of conformance tests to four security levels. FIPS 140-2 
describes the requirements for cryptographic modules and includes such areas as 
physical security, key management, self tests, roles and services, etc. The 
standard was initially developed in 1994 - prior to the development of the CC. 
CC is an evaluation against a created protection profile (PP) or security 
target (ST). Typically, a PP covers a broad range of products."

I can read the term "roles"...

If you read the "FIPS 140-2 Non-Proprietary Security Policy" you will see that:
"FIPS Mode Configuration
Local Crypto-Officer Configuration Steps"

And in the point nº 14 you can read:
"14. Edit /etc/cpshell/fips.cfg and add the following line.
expert 0 1 ?expert? ?Switch to expert mode? "

Can you figure out what that line does? Yes, it tries to block a standard 
admin/user of executing the "Expert" command, thus going into the real "root 
mode"... The FIPS configuration, eliminates the SSH, web management and other 
issues, but still allows local CLI access... I don't know if SDSUtil is 
available in such scenario -I don't think so...-, but if it is available, you 
can exploit to have Expert mode. On the other hand, what I want to show is that 
if Check Point put there an "Expert" mode, and also a configuration option to 
disable it, it seems very clear that somebody wanted to differentiate roles and 
not allowing free transitions from one profile to another. A different story is 
what happens in the real world, where almost any Secure Platform "admin" knows 
the "Expert" password. OK, now if you try to block the  Expert mode, you will 
see that can be bypassed due to the SDSUtil flaw...

Just for curiosity: the NIST FIPS paper talks about NG version, and talks about 
/etc/cpshell/fips.cfg :

expert 0 1 ?expert? ?Switch to expert mode? " 

line. In NGX R60 this is in the file:

/etc/cpshell/cpshell.cfg 

Regards,