lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 3 Oct 2007 09:46:38 -0600
From: "Tony Reusser" <>
To: <>, <>
Subject: RE: CheckPoint Secure Platform Multiple Buffer Overflows

Have you tested this against the more current release R-62?

-----Original Message-----
From: [] 
Sent: Monday, October 01, 2007 6:16 AM
Subject: CheckPoint Secure Platform Multiple Buffer Overflows

Hi all,

we have published a paper about CheckPoint Firewall-1 vulnerabilities. The
platform tested is the Secure Platform R60. We have found many buffer
overflows. Most of them are located in command line utilities that can be
exploited locally. A very few of them maybe can be exploited remotely, we
don't know...  
It seems that there's no need to be worried about this vulnerabilities, as
it seems that none of them can be exploited from remote -right now-. What
looks interesting to us is the hacking process of the target of evaluation.

As many of you know, the Check Point Secure Platform R60 was certified with
the EAL4+ Common Criteria assurance level.

Our tests to locate those vulnerabilities -many memory corruption problems-
had been very simple so we are a bit scared about the degree of reliability
of the CheckPoint development cycle. In the paper called: "Check Point
VPN-1/FireWall-1 NGX Security Target Version 1.2.2" and prepared to achieve
the certification, there is a statement like this: "the developer has
systematically searched for vulnerabilities in the TOE and provides
reasoning about why they cannot be exploited in the intended environment for
the TOE".
Systematically? We have found several overflows simply by manual fuzzing
arguments of binaries from command line....

On the other hand in the "Common Criteria Evaluation and Validation Scheme
Validation Report"  for "Check Point VPN-1/Firewall-1 NGX (R60)" -Report
Number: CCEVS-VR-06-0033- we can read: "A security reporting procedure is
available to all Enterprise Software Subscribers as well as third-party
vulnerability researchers."....
Regarding to this: we have tried to contact CheckPoint since March 2007. Six
months after that first attempt we are still unable to talk with them. We
are sure they have a "reporting procedure"... but we have not been able
read/see/listen about it. The only thing CheckPoint did from their support
email was to redirect us to our country. Unfortunately, after some contacts
with representatives of CheckPoint here in Spain we were unable to arrange a
single meeting.

OK, this is a vulnerabilities forum so let's talk about technical issues.

The interest of the released paper is the exploitation environment: RedHat
Linux + Exec-Shield + CPSHELL + many vulnerable binaries...

Summarizing, the system protections are:

- Non executable stack/heap,...
- Random stack/heap base address
- ASLR (Address Space Layout Randomization)
- ASCII Armor (libraries mapped under 16MB, so null byte in its address)
- CPSHELL - a hardened shell that only allows to run specific commands and a
very restricted sub-range of ASCII chars.

Even if we are not reinventing the wheel, I honestly think that the
exploitation scenario is far from "confortable"... At the end a P.o.C.
exploit has been released for those who want to check that the vulnerability
is really exploitable.

What we want to show is that this exploitation has been possible because of
the large number of overflows found in the target. At the end we found a
suitable one to exploit! I think this is not serious for a certified product
to have so much vulnerabilities. I think it is not serious for a firewall
vendor to have so much easily detectable bugs. 

I would like to excuse myself to the Exec-Shield developers. This paper is
not about how to bypass Exec-Shield -and have the reader into account we are
evaluating an old version- but is about Check Point firewall security.
Kernel patches are a must but we must not rely on them. Buggy software is
difficult to protect, even by the most advanced kernel protections.
Exec-Shield is a wonderful work and I have learned a lot by reading its

The paper can be downloaded from:



Hugo Vázquez Caramés

"There are only 10 types of people in the world: Those who understand
binary, and those who don't"

PENTEST Consultores
Tel: 93 3962070 / Fax: 93 3962001
Gane credibilidad y confianza, visite

Powered by blists - more mailing lists