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,