Message-ID: <20071017004222.9519.qmail@securityfocus.com>
Date: 17 Oct 2007 00:42:22 -0000
From: hvazquez@...test.es
To: bugtraq@...urityfocus.com
Subject: 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,

Powered by blists - more mailing lists